httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@leland.Stanford.EDU>
Subject Re: [Fwd: Problem 2534]
Date Tue, 04 Aug 1998 00:00:05 GMT
On Mon, 3 Aug 1998, Dean Gaudet wrote:

> Uh, no there's nothing to make more clear to the compiler.  The code is
> correct, the compiler cannot combine those symbols.

No one is combining symbols. We're talking about a compiler erroneously
seperating symbols (this is back to the actual problem, and not the whole
pointer/array theory thing).

We have in http_core.c, for example end_directory_section:

static const char end_directory_section[] = "</Directory>";
static const command_rec core_cmds[] = {
{ end_directory_section, end_nested_section, NULL, ACCESS_CONF, NO_ARGS,
  "Marks end of <Directory>" },

Plus end_directory_section is used in a few functions, e.g., checking to
see if we reached the end of a section (this is where we're running into

Now, end_directory_section gets declared and initialized to be a
thirteen-character array somewhere in global memory. The other uses of
end_directory_section are equivilent to &end_directory_section[0], that is
they use the address of the first character ('<') of
end_directory_section. Which should be constant.

My contention is that somehow, because of oddities in some
compiler/linker's code that does variable initialization, when it gets to
the end_directory_section in core_cmds, it doesn't correctly point to the
string, possibly because it hasn't been created yet, but makes its own
copy of it. Yes, this doesn't make any sense. But it could explain what's

If we changed the declaration to

static const char *end_directory_section = "</Directory>";

Then the semantics should be the same, with the added bonus that the
pointer value of end_directory_section is now directly available; it
doesn't have to be computed, so there's less possibility for a compiler to
screw up (and the string "</Directory>" doesn't have to exist for the
pointer to).

Okay, so maybe it doesn't make much sense. But it 'feels' better. And it
saves 77 bytes (copy-on-write notwithstanding) per process :)

-- Alexei Kosut <> <>
   Stanford University, Class of 2001 * Apache <> *

View raw message