> Olivier Antoine wrote:
> > Hi all,
> > 
> > Recently a bug has been identified in Tor:
> > 
> > https://trac.torproject.org/projects/tor/ticket/22789
> > 
> > As comments were made, questions were raised about the use of strtol(3),
> > the different interpretations of the standard and their implementation.
> > 
> > To summarize, the question revolves around the processing of strings in
> > base=16 and with the optional prefix '0x'.
> > 
> > l = strtol ("0xquux", & rest, 16);
> > 
> > Produce
> > l=0 rest=0xquux on OpenBSD
> > l=0 rest=xquux on Linux
> > 
> > Do specialists of the standard or developers have an opinion on this point
> > of detail?
> > Is there a defined behavior?
> 
> My opinion is that well written code would avoid feeding ambigious strings to
> strtol. Today's it's 0xquux and tomorrow it's 0xaquux and now you have a
> problem.
> 
> But, let's read 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html
> 
> It's actually unclear IMO. But I don't see anything prohibiting interpreting
> the string as an optional prefix with an empty body.
> 
> I'm inclined to say that strtol parsing should involve minimal lookahead and
> backtracking. So if it sees 0x, it thinks hex prefix, and then parses the
> rest. It doesn't try parsing the rest, fail, and then backtrack and start over
> with a new parse strategy.

What does the original code from AT&T do?

Does the BSD 4.0 code do the same?

How about the BSD 4.2 code?

How about the BSD 4.4 code?

How about all the vendors who simply used that code unmodified?

Who is the outlier?

Is it glibc?

Is it possible the spec wasn't written in a proscriptive fashion?

How much code breaks as a result?

I expect some language layering will happen over this in the next year.

I wonder if some people are going to say "the original way of doing
this is so wrong, glibc does it so much better, and the written text
lets us get away with it no matter how much code it affects".

Always fun.

Reply via email to