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: Mel on 1 Jul 2010 11:36 Nobody wrote: > On Wed, 30 Jun 2010 23:40:06 -0600, Michael Torrie wrote: >> Given "char buf[512]", buf's type is char * according to the compiler >> and every C textbook I know of. References from Kernighan & Ritchie _The C Programming Language_ second edition: > No, the type of "buf" is "char [512]", i.e. "array of 512 chars". If you > use "buf" as an rvalue (rather than an lvalue), it will be implicitly > converted to char*. K&R2 A7.1 > If you take its address, you'll get a "pointer to array of 512 chars", > i.e. a pointer to the array rather than to the first element. Converting > this to a char* will yield a pointer to the first element. K&R2 A7.4.2 ��������Mel.
From: Michael Torrie on 1 Jul 2010 12:10 On 07/01/2010 01:24 AM, Nobody wrote: > No, the type of "buf" is "char [512]", i.e. "array of 512 chars". If you > use "buf" as an rvalue (rather than an lvalue), it will be implicitly > converted to char*. Yes this is true. I misstated. I meant that most text books I've seen say to just use the variable in an *rvalue* as a pointer (can't think of any lvalue use of an array). K&R states that arrays (in C anyway) are always *passed* by pointer, hence when you pass an array to a function it automatically decays into a pointer. Which is what you said. So no need for & and the compiler warning you get with it. That's all. If the OP was striving for pedantic correctness, he would use &buf[0].
From: John Nagle on 1 Jul 2010 13:17 On 7/1/2010 8:36 AM, Mel wrote: > Nobody wrote: >> On Wed, 30 Jun 2010 23:40:06 -0600, Michael Torrie wrote: >>> Given "char buf[512]", buf's type is char * according to the compiler >>> and every C textbook I know of. > > References from Kernighan& Ritchie _The C Programming Language_ second > edition: > >> No, the type of "buf" is "char [512]", i.e. "array of 512 chars". If you >> use "buf" as an rvalue (rather than an lvalue), it will be implicitly >> converted to char*. Yes, unfortunately. The approach to arrays in C is just broken, for historical reasons. To understand C, you have to realize that in the early versions, function declarations weren't visible when function calls were compiled. That came later, in ANSI C. So parameter passing in C is very dumb. Billions of crashes due to buffer overflows later, we're still suffering from that mistake. But this isn't a Python issue. John Nagle
From: Lawrence D'Oliveiro on 1 Jul 2010 19:47 In message <mailman.2370.1277871088.32709.python-list(a)python.org>, Michael Torrie wrote: > 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. So persuade me. I have given an example of code written the way I do it. Now let's see you rewrite it using your preferred technique, just to prove that your way is simpler and easier to understand. Enough hand-waving, let's see some code!
From: Lawrence D'Oliveiro on 1 Jul 2010 19:50
In message <4c2ccd9c$0$1643$742ec2ed(a)news.sonic.net>, John Nagle wrote: > The approach to arrays in C is just broken, for historical reasons. Nevertheless, it it at least self-consistent. To return to my original macro: #define Descr(v) &v, sizeof v As written, this works whatever the type of v: array, struct, whatever. > So parameter passing in C is very dumb. Nothing to do with the above issue. |