[rfc][icedtea-web] c-properties-miniparser now escape most (all except multiline?) escape sequences

[Jiri Vanek]

Thank you v.m. for suggestions. Its pushed now.

How do you feel about 1.6 backport? It *is* change in behaviour, but I still see 1.7 in at least 
half an year....

J.
On 12/22/2015 05:08 PM, Jakob Wisor wrote:
> On 12/22/2015 at 02:01 PM Jiri Vanek wrote:
>> On 12/22/2015 09:58 AM, Jacob Wisor wrote:
>>> On 12/18/2015 at 04:12 PM Jiri Vanek wrote:
>>>> SSIA
>>>>
>>>> how about 1.6 ? Backport?
>>>
>>> This code is supposed to work on manifest files in JAR files and property,
>>> files right?
>>
>> It is parsing only selected items from deployment.properties (jvm home and the
>> plugin arguments)
>
> Okay, thank you for the clarification.
>
>>>> […]
>>>> +                char c2 = str[i+1];
>>>> +                if (c2 == '=' || c2 == '\\' || c2 == ':') {
>>>> +                    result+=c2;
>>>> +                    i++;
>>>> +                    processed = true;
>>>> +                }
>>>> +                if (c2 == 't') {
>>>> +                    result+='\t';
>>>> +                    i++;
>>>> +                    processed = true;
>>>> +                }
>>>> +                if (c2 == 'n') {
>>>> +                    result+='\n';
>>>> +                    i++;
>>>> +                    processed = true;
>>>> +                }
>>>> +                if (c2 == 'r') {
>>>> +                    result+='\r';
>>>> +                    i++;
>>>> +                    processed = true;
>>>> +                }
>>>
>>> I suppose a cascading "if else" structure would be more efficient here.
>>
>> I had this in first (not published version). It maybe is 0.0000000001% faster
>> but it really do not look nicely.
>>
>> I would much rather stay with this style.
>
> Well, it does not cost much to type this nor does it really look much different, since you've
> brought up /style/. It's just a stupid thing to do; waste CPU cycles and energy on every launch of
> IcedTea-Web. Sure, there is plenty of other stuff in IcedTea-Web which has been coded in a wasteful
> way but one should start at least somewhere. So, why not here. Just multiply this waste with the
> number of machines running IcedTea-Web and launching applications every day! Energy efficiency is
> king of the 21st century.
>
>>>> […]
>>> For one, please fix the formatting and remove trailing white spaces at the end
>>> of lines.
>>>
>> Should be fixed.
>
> Great! :-)
>
>>> Second, is this really a good way to do escape sequence processing in C/C++?
>>> I'd say that regex
>>
>> As far as I'm able to judge (with local C gurus)... yes...
>>
>> As for regexes. I'm not best C man (crap :D)  so I was consulting with others.
>> And .. before I consulted, I went with regexes. The result was terrible 9 Tired
>> a *lot*) and I was strongly discouraged later.
>>
>> Then I swapped to this, realised taht this really is it is much much cleaner and
>> better solution.
>
> To be honest, I am surprised they gave you this advice because almost all native string functions
> have been heavily optimized on all significant platforms in the last 40 years, especially in the
> POSIX world. Most operating system and CPU manufacturers have invested a lot into features to handle
> common string operations efficiently. This may have been forgotten because of an explosion of other
> quickly evolving exciting technologies since the dawn of the internet. But in fact, after decades of
> research and dozens of PhD works on this topic, technology has got very sophisticated at handling
> strings, often outperforming what the average C coder can produce. But I won't insist, I am just
> surprised.
>
>>> […
>>
>> Well thsi is painful storry. Now I'm happy I'm staying with that iteration.
>
> Well, as long as it is logically correct, works as intended, and not overly inefficient, I am okay
> with it.
>
> Regards,
>
> Jacob
>