On Feb 23,  3:36am, Greywolf wrote:
} 
} 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.

     More like just plain broken.

} 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

     The string literal is a const which can't be changed.

} an rvalue, while the latter is restricted to a string literal only --

     In this case, the string literal is only an initialiser for the
array and can be changed.

} statements of the form (given "extern char _xstr[];")
} 
} 	static char bar[] = (&_xstr[99]);
} 
} are not considered valid input to gcc.

     Not surprising since an array is not a pointer.

} I see the following solutions to the second problem:
} 
} 1.  Obsolete xstr.  I'm not sure if this is desirable or not;

     Probably not, but it does need to be taught the C language.

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

     Absolutely not!  An array is not a pointer!  They have different
semantics and blindly converting between them could really screw up a
program.

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

     No, they have different uses.

} 4.  Update all sources to use
} 
} 	#ifdef __xstr__
} 	static char *foo
} 	#else
} 	static char foo[]
} 	#endif
} 			= "initialiser";

     No, this would horribly complicate a program.

} Questions?  Comments?  Where do we go from here?

     The only acceptable thing is to collapse string constants, but to
leave array initialisers alone.  String constants are allowed to live
in read-only storage and thus aren't allowed to be change; however, the
contents of arrays can be changed.

}-- End of excerpt from Greywolf