Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncrcae!ece-csc!mcnc!thorin!unc!alexande
From: alexande@unc.cs.unc.edu (Geoffrey D. Alexander)
Newsgroups: comp.unix.wizards
Subject: Re: Problem with xstr
Summary: I beg to differ
Message-ID: <4322@thorin.cs.unc.edu>
Date: 22 Sep 88 01:09:36 GMT
References: <4252@thorin.cs.unc.edu> <145@taux02.UUCP>
Sender: news@thorin.cs.unc.edu
Lines: 21

In article <145@taux02.UUCP>, amos@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