Files
seta75D ff309bfe1c Init
2021-10-11 18:37:13 -03:00

166 lines
3.4 KiB
Groff

.\" @(#)xstr.1 1.1 94/10/31 SMI; from UCB 4.2
.TH XSTR 1 "19 April 1989"
.SH NAME
xstr \- extract strings from C programs to implement shared strings
.SH SYNOPSIS
.B xstr
.B \-c
.I filename
[
.B \-v
]
[
.B \-l
.I array
]
.br
.B xstr
[
.B \-l
.I array
]
.br
.B xstr
.I filename
[
.B \-v
] [
.B \-l
.I array
]
.IX "xstr command" "" "\fLxstr\fP \(em extract strings from C code"
.IX "extract strings from C code" "" "extract strings from C code \(em \fLxstr\fP"
.IX "programming languages" xstr "" "\fLxstr\fP \(em extract strings from C code"
.IX languages xstr "" "\fLxstr\fP \(em extract strings from C code"
.IX "C programming language" xstr "" "\fLxstr\fP \(em extract strings from C code"
.SH DESCRIPTION
.B xstr
maintains a file called
.B 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.
.LP
The command
.IP
.BI "xstr \-c " filename
.LP
extracts the strings from the C source in name, replacing
string references by expressions of the form
.BI &xstr[ number ]
for some number. An appropriate declaration of
.B xstr
is prepended to the file. The resulting C text is placed in the file
.B x.c,
to then be compiled. The strings from
this file are placed in the
.B 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.
.LP
After all components of a large program have been compiled, a file
declaring the common
.B xstr
space called
.B xs.c
can be created by a command of the form
.IP
.B xstr
.LP
This
.B 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.
.LP
.B xstr
can also be used on a single file. A
command
.IP
.BI "xstr "filename
.LP
creates files
.B x.c
and
.B xs.c
as before, without using or affecting any
.B strings
file in the same directory.
.LP
It may be useful to run
.B 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.
.B xstr
reads from the standard input when the argument
.RB ` \- '
is given.
An appropriate command sequence for running
.B xstr
after the C preprocessor
is:
.IP
.nf
.ft B
cc \-E name.c | xstr \-c \-
cc \-c x.c
mv x.o name.o
.ft R
.fi
.LP
.B xstr
does not touch the file
.B strings
unless new items are added; thus
.BR make (1)
can avoid remaking
.B xs.o
unless truly necessary.
.SH OPTIONS
.TP 12
.BI "\-c "filename
Take C source text from
.IR filename .
.TP
.B \-v
Verbose: display a progress report indicating where new or
duplicate strings were found.
.TP
.BI "\-l "array
Specify the named
.I array
in program references to abstracted strings. The default array
name is
.BR xstr .
.SH FILES
.PD 0
.TP 20
.B strings
data base of strings
.TP
.B x.c
massaged
C source
.TP
.B xs.c
C source for definition of array \*(lqxstr\*(rq
.TP
.B /tmp/xs*
temp file when
.BI "xstr "filename
doesn't touch
.B strings
.PD
.SH "SEE ALSO"
.BR make (1),
.BR mkstr (1)
.SH BUGS
If a string is a suffix of another string in the data base,
but the shorter string is seen first by
.B xstr
both strings will be placed in the data base, when just
placing the longer one there would do.