Problem with xstr

[Geoffrey D. Alexander]

In article <145 at taux02.UUCP>, amos at taux02.UUCP (Amos Shapir) writes:
> Unless you use a pdp11 with separate  I/D space, the solution is to just
> throw out all  the xstr stuff from your makefiles,  and compile normally
> instead.
> 
> Xstr is a hack for putting  strings, which are supposed to be read-only,
> into the executable's  text (code) space. This makes more  room for data
> on  machines  with  limited  address space.  On  32-bit  machines,  this
> approach is obsolete and causes more trouble than benefit.

I beg to differ.  I am running on SUNs (2, 3 and 4).  The SUN C compiler
generates a seperate copy of a string each time it occurs.  If I have a string
in a nested macro, this could get expensive.  For example, say I have a 99
character string in a macro that gets invoked 100 times.  Thus, without xstr
the string storage is 10,000 bytes, with xstr it is 100 bytes.  Multiply this
by a few dozen strings.  You end up with a significant savings in program size.

I have yet to receive an answer to my question.  Does anyone know how to make
xstr handle large lines potentially generated by the C preprocessor?

Geoff Alexander