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: Michael Torrie on 30 Jun 2010 00:11 On 06/29/2010 06:26 PM, Lawrence D'Oliveiro wrote: >> I'm not sure you understood me correctly, because I advocate >> *not* doing input sanitization. Hard or not -- I don't want to know, >> because I don't want to do it. > > But no-one has yet managed to come up with an alternative that involves less > work. Your case is still not persuasive. How is using the DB API's placeholders and parameterization more work? It's the same amount of keystrokes, perhaps even less. You would just be substituting the API's parameter placeholders for Python's. In fact with Psycopg2 and the mysql python db apis, it's almost a matter of simply removing the "%" and putting in a comma, turning python's string substitution into a method call. And you can leave out the quotes around where the variables go. If I have to sanitize every input, I have to do it on each and every field on each and every form action. With the DB API doing the work I just do it once, in one place. Is this not easier that manually escaping everything and then embedding it in the query string? I've not used sqlalchemy, but it looks similarly easy.
From: Michael Torrie on 30 Jun 2010 00:17 On 06/29/2010 10:05 PM, Michael Torrie wrote: > #include <stdio.h> > > int main(int argc, char ** argv) > { > char *buf = malloc(512 * sizeof(char)); > const int a = 2, b = 3; > snprintf(&buf, sizeof buf, "%d + %d = %d\n", a, b, a + b); ^^^^^^^^^^ Make that 512*sizeof(buf) Still segfaults though. > fprintf(stdout, buf); > free(buf); > return 0; > } /*main*/
From: Michael Torrie on 30 Jun 2010 00:28 On 06/29/2010 10:17 PM, Michael Torrie wrote: > On 06/29/2010 10:05 PM, Michael Torrie wrote: >> #include <stdio.h> >> >> int main(int argc, char ** argv) >> { >> char *buf = malloc(512 * sizeof(char)); >> const int a = 2, b = 3; >> snprintf(&buf, sizeof buf, "%d + %d = %d\n", a, b, a + b); > ^^^^^^^^^^ > Make that 512*sizeof(buf) Sigh. Try again. How about "512 * sizeof(char)" ? Still doesn't make a different. The code still crashes because the &buf is incorrect. Another reason python programming is just so much funner and easier! This little diversion is fun though. C is pretty powerful and I enjoy it, but it sure keeps one on one's toes. I made a similar mistake to the &buf thing years ago when I thought I could return strings (char *) from functions on the stack the way Pascal and BASIC could. It was only by pure luck that my code worked as the part of the stack being accessed was invalid and could have been overwritten. >> fprintf(stdout, buf); >> free(buf); >> return 0; >> } /*main*/
From: Carl Banks on 30 Jun 2010 00:49 On Jun 28, 2:44 am, Gregory Ewing <greg.ew...(a)canterbury.ac.nz> wrote: > 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*. I can't think of any function in the standard library that observes that convention, which inclines me to disbelieve this convention ever really existed. If it did, there would be functions to support it. For that matter, I'm not really inclined to believe bytes were *that* precious in those days. > 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. Well, no. Being cognizant of the string's maximum length doesn't make you able to pass it to printf, or system, or any other C function. The obvious rationale behind strncpy's stupid behavior is that it's not a string function at all, but a memory block function, that stops at a NUL in case you don't care what's after the NUL in a block. But it leads you to believe it's a string function by it's name. Carl Banks
From: Jorgen Grahn on 30 Jun 2010 05:00
On Wed, 2010-06-30, Michael Torrie wrote: > On 06/29/2010 10:17 PM, Michael Torrie wrote: >> On 06/29/2010 10:05 PM, Michael Torrie wrote: >>> #include <stdio.h> >>> >>> int main(int argc, char ** argv) >>> { >>> char *buf = malloc(512 * sizeof(char)); >>> const int a = 2, b = 3; >>> snprintf(&buf, sizeof buf, "%d + %d = %d\n", a, b, a + b); >> ^^^^^^^^^^ >> Make that 512*sizeof(buf) > > Sigh. Try again. How about "512 * sizeof(char)" ? Still doesn't make > a different. The code still crashes because the &buf is incorrect. I haven't tried to understand the rest ... but never write 'sizeof(char)' unless you might change the type later. 'sizeof(char)' is by definition 1 -- even on odd-ball architectures where a char is e.g. 16 bits. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |