te
Copyright (c) 1992, Sun Microsystems, Inc.
The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
xstr - extract strings from C programs to implement shared strings

xstr -c filename [-v] [-l array]

xstr [-l array]

xstr filename [-v] [-l array]

xstr maintains a file called 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, which are most useful if they are also read-only.

The command:

example% xstr -c filename

extracts the strings from the C source in name, 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.

After all components of a large program have been compiled, a file declaring the common xstr space called xs.c can be created by a command of the form:

example% xstr

This xs.c file 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. A command:

example% xstr filename

creates files x.c and xs.c as before, without using or affecting any strings file in the same directory.

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. xstr reads from the standard input when the argument `-' is given. An appropriate command sequence for running xstr after the C preprocessor is:

example% cc -E name.c | xstr -c -
example% cc -c x.c
example% mv x.o name.o

xstr does not touch the file strings unless new items are added; thus make(1S) can avoid remaking xs.o unless truly necessary.

-c filename -v -l array strings x.c xs.c /tmp/xs*

make (1S), attributes (7)

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 would do.

Be aware that xstr indiscriminately replaces all strings with expressions of the form &xstr[number] regardless of the way the original C code might have used the string. For example, you will encounter a problem with code that uses sizeof() to determine the length of a literal string because xstr will replace the literal string with a pointer that most likely will have a different size than the string's. To circumvent this problem:

You will also encounter a problem when declaring an initialized character array of the form

char x[] = "xxx";

xstr will replace xxx with an expression of the form &xstr[number] which will not compile. To circumvent this problem, use static char *x = "xxx" instead of static char x[] = "xxx".