NAME
xstr —
extract strings from C programs
to implement shared strings
SYNOPSIS
xstr |
[-cv]
[-l array]
[-]
[file ...] |
DESCRIPTION
xstr maintains a file
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:
-
-
- -
- xstr reads from the standard input.
-
-
- -c
- xstr will extract the strings from the C
source file or the standard input
(-), replacing string references by expressions of the
form (&xstr[number]) for some number. An appropriate declaration of
xstr is prepended to the file. The resulting C text is
placed in the file 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.
-
-
- -l
array
- Specify the named array in program references to abstracted
strings. The default array name is xstr.
-
-
- -v
- Be verbose.
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.
FILES
- strings
- Data base of strings
- x.c
- Massaged C source
- xs.c
- C source for definition of array `xstr'
- /tmp/xs*
- Temp file when `xstr name' doesn't touch
strings
SEE ALSO
mkstr(1)
HISTORY
The
xstr command appeared in
3.0BSD.
BUGS
If a string is a suffix of another string in the data base, but the shorter
string is seen first by
xstr both strings will be placed in
the data base, when just placing the longer one there will do.
xstr does not parse the file properly so it does not know not
to process:
into:
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:
struct foo {
int i;
char buf[10];
} = {
1, "foo"
};
to:
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.