Message98657
| Author |
pitrou |
| Recipients |
Rhamphoryncus, ajaksu2, amaury.forgeotdarc, benjamin.peterson, collinwinter, eric.smith, ezio.melotti, ferringb, gvanrossum, jafo, jimjjewett, lemburg, mark.dickinson, orivej, pitrou, rhettinger, terry.reedy |
| Date |
2010年02月01日.11:39:52 |
| SpamBayes Score |
9.328094e-13 |
| Marked as misclassified |
No |
| Message-id |
<1265024472.3326.7.camel@localhost> |
| In-reply-to |
<4B66AF53.3090605@egenix.com> |
| Content |
> I'd consider that a bug. Esp. the IO lib should be 8-bit clean
> in the sense that it doesn't add any special meaning to NUL
> characters or code points.
It doesn't add any special meaning to them. It just relies on a NUL
being present after the end of the string. It doesn't care about other
NULs.
> Besides, using a for-loop with a counter is both safer and faster
> than checking each an every character for NUL.
It's slower, since it has one more condition to check.
Newline detection as it is written has a fast path in the form of:
while (*c++ >= 0x20);
> Just think of what can happen if you have buggy code that overwrites
> the NUL byte in some corner case situation and then use the assumption
> of having the NUL byte as terminator - a classical buffer overrun.
Well, buggy code leads to bugs :) |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2010年02月01日 11:39:54 | pitrou | set | recipients:
+ pitrou, lemburg, gvanrossum, collinwinter, rhettinger, terry.reedy, jafo, jimjjewett, amaury.forgeotdarc, mark.dickinson, Rhamphoryncus, eric.smith, ferringb, ajaksu2, benjamin.peterson, orivej, ezio.melotti |
| 2010年02月01日 11:39:53 | pitrou | link | issue1943 messages |
| 2010年02月01日 11:39:52 | pitrou | create |
|