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