httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: [Fwd: Problem 2534]
Date Mon, 03 Aug 1998 23:52:03 GMT
On Mon, 3 Aug 1998, Alexei Kosut wrote:

> On Mon, 3 Aug 1998, Jim Jagielski wrote:
> > Alexei Kosut wrote:
> > > 
> > > (Recall that arrays and pointers are not the same thing in C, no matter
> > > how alike they may act)
> > > 
> > 
> > Yep... that's why I suggested changing the decalrations from [] to *
> > for the "end_" variables in question... Mostly likely, this would make
> > is clearer to the compiler what we mean.
> Yes, this sounds like a good idea to me. While the array-to-pointer
> conversions are well-defined (pointer = &array[0]), this just strikes me
> as something that a compiler, especially a well-meaning optimizing
> compiler, could screw up. While theoretically, a pointer to an array
> should always give the same result, using a pointer directly ensures it,
> hmm? (since there is actually a word in memory somewhere that actually
> contains the pointer address, instead of it being calculated each time
> it's needed)
> +1, regardless of whether or not it solves the problem :)
> I mean, heck, it would save a whole 77 bytes of memory per process!

I don't understand how you're coming to this conclusion either:

    char foo[] = "hello";

consumes 6 bytes of memory;

    char *foo = "hello";

consumes 10 bytes of memory (on a 32-bit box).

Furthermore, the first example allows the compiler to generate constants
inline (with attached relocations).  This favours boxes like the x86 which
allow 32-bit constants in the instruction stream.  The second example
requires the compiler to load memory first.  There's little difference
between the two on RISC processors. 

Yeah yeah, it's me being picky about optimization, but hell, it's not like
I went in there with the express purpose of making it faster.  I went in
there to fix a bug, and in the process made the code more efficient.  I
don't understand why we're arguing about a bug in one version of the
compiler on AIX -- just turn off optimization.  We didn't bend over
backwards to suit SCO's broken compilers -- we just told people to turn
off optimization. 


View raw message