strings
into which strings in component parts of a large program are hashed.
These strings are replaced with references to this common area.
This serves to implement shared constant strings, most useful if they
are also read-only.
Available options:
x.c
,
to then be compiled.
The strings from this file are placed in the
strings
data base if they are not there already.
Repeated strings and strings which are suffixes of existing strings
do not cause changes to the data base.
After all components of a large program have been compiled, a file
xs.c
declaring the common
xstr
space can be created by a command of the form:
$
xstr
The file
xs.c
should then be compiled and loaded with the rest
of the program.
If possible, the array can be made read-only (shared) saving
space and swap overhead.
xstr
can also be used on a single file.
The following command creates files
x.c
and
xs.c
as before, without using or affecting any
strings
file in the same directory:
$
xstr
name
It may be useful to run xstr after the C preprocessor if any macro definitions yield strings or if there is conditional code which contains strings which may not, in fact, be needed. An appropriate command sequence for running xstr after the C preprocessor is:
$ cc -E name.c | xstr -c -
$ cc -c x.c
$ mv x.o name.o
xstr
does not touch the file
strings
unless new items are added, thus
make(1)
can avoid remaking
xs.o
unless truly necessary.
strings
x.c
xs.c
/tmp/xs*
strings
xstr
does not parse the file properly so it does not know not to process:
into:
char var[] = "const";
char var[] = (&xstr[N]);
These must be changed manually into an appropriate initialization for the string, or use the following ugly hack.
Also,
xstr
cannot initialize structures and unions that contain strings.
Those can be fixed by changing from:
to:
struct foo {
int i;
char buf[10];
} = {
1, "foo"
};
struct foo {
int i;
char buf[10];
} = {
1, { 'f', 'o', 'o', '\0' }
};
The real problem in both cases above is that the compiler knows the size of the literal constant so that it can perform the initialization required, but when xstr changes the literal string to a pointer reference, the size information is lost. It would require a real parser to do this right, so the obvious solution is to fix the program manually to compile, or even better rely on the compiler and the linker to merge strings appropriately.
Finally, xstr is not very useful these days because most of the string merging is done automatically by the compiler and the linker, provided that the strings are identical and read-only.