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

Jakob Wisor gitne at gmx.de
Tue Dec 22 16:08:49 UTC 2015

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.



More information about the distro-pkg-dev mailing list