Why Is Escaping Data Considered So Magical?
in [Python]
|
Prev: GDAL-1.7.1 : vcvarsall.bat missing
Next: improving python performance by extension module (64bit)
From: Kushal Kumaran on 28 Jun 2010 00:54 On Mon, Jun 28, 2010 at 2:00 AM, Jorgen Grahn <grahn+nntp(a)snipabacken.se> wrote: > On Sun, 2010-06-27, Lawrence D'Oliveiro wrote: >> In message <roy-854954.20435125062010(a)news.panix.com>, Roy Smith wrote: >> >>> I recently fixed a bug in some production code. Â The programmer was >>> careful to use snprintf() to avoid buffer overflows. Â The only problem >>> is, he wrote something along the lines of: >>> >>> snprintf(buf, strlen(foo), foo); >> >> A long while ago I came up with this macro: >> >> Â Â #define Descr(v) &v, sizeof v >> >> making the correct version of the above become >> >> Â Â snprintf(Descr(buf), foo); > > This is off-topic, but I believe snprintf() in C can *never* safely be > the only thing you do to the buffer: you also have to NUL-terminate it > manually in some corner cases. See the documentation. > snprintf goes to great lengths to be safe, in fact. You might be thinking of strncpy. -- regards, kushal
From: Carl Banks on 28 Jun 2010 01:07 On Jun 27, 9:54 pm, Kushal Kumaran <kushal.kumaran+pyt...(a)gmail.com> wrote: > On Mon, Jun 28, 2010 at 2:00 AM, Jorgen Grahn <grahn+n...(a)snipabacken.se> wrote: > > On Sun, 2010-06-27, Lawrence D'Oliveiro wrote: > >> In message <roy-854954.20435125062...(a)news.panix.com>, Roy Smith wrote: > > >>> I recently fixed a bug in some production code. The programmer was > >>> careful to use snprintf() to avoid buffer overflows. The only problem > >>> is, he wrote something along the lines of: > > >>> snprintf(buf, strlen(foo), foo); > > >> A long while ago I came up with this macro: > > >> #define Descr(v) &v, sizeof v > > >> making the correct version of the above become > > >> snprintf(Descr(buf), foo); > > > This is off-topic, but I believe snprintf() in C can *never* safely be > > the only thing you do to the buffer: you also have to NUL-terminate it > > manually in some corner cases. See the documentation. > > snprintf goes to great lengths to be safe, in fact. You might be > thinking of strncpy. Indeed, strncpy does not copy that final NUL if it's at or beyond the nth element. Probably the most mind-bogglingly stupid thing about the standard C library, which has lots of mind-boggling stupidity. Whenever I do an audit of someone's C code the first thing I do is search for strncpy and see if they set the nth character to 0. (They usually didn't.) Carl Banks
From: Stephen Hansen on 26 Jun 2010 23:27 On 6/26/10 7:21 PM, Lawrence D'Oliveiro wrote: > In message<mailman.2123.1277522976.32709.python-list(a)python.org>, Tim Chase > wrote: > >> On 06/25/2010 07:49 PM, Lawrence D'Oliveiro wrote: >> ... > > I see that you published my unobfuscated e-mail address on USENET for all to > see. I obfuscated it for a reason, to keep the spammers away. I'm assuming > this was a momentary lapse of judgement, for which I expect an apology. > Otherwise, it becomes grounds for an abuse complaint to your ISP. Wow. Way to be a douchebag. I was going to say something about the realities of this forum and its dual-nature and conflicting netiquette and on. But I decided it really just had no point. So, I'm left with: wow. You kinda suck*, man. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ P.S. *Then again, I'm fairly sure anytime someone has a form letter which contains the words, "I expect an apology", there's some personal suck going on.
From: Jorgen Grahn on 28 Jun 2010 03:58 On Mon, 2010-06-28, Kushal Kumaran wrote: > On Mon, Jun 28, 2010 at 2:00 AM, Jorgen Grahn <grahn+nntp(a)snipabacken.se> wrote: >> On Sun, 2010-06-27, Lawrence D'Oliveiro wrote: >>> In message <roy-854954.20435125062010(a)news.panix.com>, Roy Smith wrote: >>> >>>> I recently fixed a bug in some production code. �The programmer was >>>> careful to use snprintf() to avoid buffer overflows. �The only problem >>>> is, he wrote something along the lines of: >>>> >>>> snprintf(buf, strlen(foo), foo); >>> >>> A long while ago I came up with this macro: >>> >>> � � #define Descr(v) &v, sizeof v >>> >>> making the correct version of the above become >>> >>> � � snprintf(Descr(buf), foo); >> >> This is off-topic, but I believe snprintf() in C can *never* safely be >> the only thing you do to the buffer: you also have to NUL-terminate it >> manually in some corner cases. See the documentation. > > snprintf goes to great lengths to be safe, in fact. You might be > thinking of strncpy. Yes, it was indeed strncpy I was thinking of. Thanks. But actually, the snprintf(3) man page I have is not 100% clear on this issue, so last time I used it, I added a manual NUL-termination plus a comment saying I wasn't sure it was needed. I normally use C++ or Python, so I am a bit rusty on these things. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
From: Gregory Ewing on 28 Jun 2010 05:44
Carl Banks wrote: > Indeed, strncpy does not copy that final NUL if it's at or beyond the > nth element. Probably the most mind-bogglingly stupid thing about the > standard C library, which has lots of mind-boggling stupidity. I don't think it was as stupid as that back when C was designed. Every byte of memory was precious in those days, and if you had, say, 10 bytes allocated for a string, you wanted to be able to use all 10 of them for useful data. So the convention was that a NUL byte was used to mark the end of the string *if it didn't fill all the available space*. Functions such as strncpy and snprintf are designed for use with strings that follow this convention. Proper usage requires being cognizant of the maximum length and using appropriate length-limited functions for all operations on such strings. -- Greg |