Minix Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
XSTR(1)                   BSD General Commands Manual                  XSTR(1)

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:

             char var[] = "const";
     into:

             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:

             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.

BSD                              July 23, 2004                             BSD

NAME | SYNOPSIS | DESCRIPTION | FILES | SEE ALSO | HISTORY | BUGS