[please redirect as needed, preferably not to /dev/null...]

After some courage and some digging, I finally found out what's
breaking with SHAREDSTRINGS.  It appears that xstr produces output
which is obsolete -- or at least gcc 3.3.1 does not want to play
well with it.

The first problem is that xstr wants to convert all lines of the format

# <lineno> "file" tokens

into

#line "file" tokens

a construct which cpp does not accept.  This is easily rectified by disabling
the section which converts the former into the latter in xstr.

The other problem is that of the semantic difference between

	static char *foo = (something);

and

	static char bar[] = (something);

The former can have either a string literal or a reference given to it as
an rvalue, while the latter is restricted to a string literal only --
statements of the form (given "extern char _xstr[];")

	static char bar[] = (&_xstr[99]);

are not considered valid input to gcc.

I see the following solutions to the second problem:

1.  Obsolete xstr.  I'm not sure if this is desirable or not;

2.  Update xstr to either leave the RHS of static char [] alone or
    convert it to static char *;

3.  Update all sources to use static char *foo instead of static char foo[];

4.  Update all sources to use

	#ifdef __xstr__
	static char *foo
	#else
	static char foo[]
	#endif
			= "initialiser";

    [ignore the horrid formatting; I tend sometimes to think in strange terms]

    and update the .mk files to add -D__xstr__ to CPPFLAGS or update xstr
    to prepend "#define __xstr__" to its output.

#1 looks like it might be the most expedient option, but I don't know that
it's the most practical.  Given the prevalent attitude these days of
"I have tons of ram and a killer processor so I don't really give a",
the people in that camp probably won't miss the benefit that xstr gives.

#2 appears to be non-trivial in terms of programming effort, at least to
me, having looked at the code.  It processes most things in a character-
at-a-time wander through the file; its parser is most rudimentary.  Changing
static char foo[] to static char *foo appears to me to be a violation of
the language spec, or at least the intentions therein.

#3 seems to me to be a language violation as well as requiring a non-trivial
amount of effort in terms of code changes and checkins and things, although
this at least looks like it could be automated with a relatively simple
script.

#4 seems to be like #3 on a high-fibre diet, requiring more than non-trivial
amounts of effort in terms of code changes and greater amounts of manual
processing.

Questions?  Comments?  Where do we go from here?

If we don't obsolete xstr completely, I should probably at least send-pr
the change which causes it not to spit out "#line" directives, but even
there, I don't know -- are there compilers which *require* "#line" instead
of "# <lineno>" ?  I've certainly never seen a compiler break like this
before.

[If it turns out to be a compiler bug instead, well, this whole letter was
moot, then...]

				--*greywolf;
--
NetBSD: The cure for the common OS.