Remove building with NOCRYPTO option
[minix3.git] / usr.bin / xstr / xstr.1
blobdd0e9813c56bcd754a908adcaf413ee47ef282d1
1 .\"     $NetBSD: xstr.1,v 1.18 2005/09/11 23:29:44 wiz Exp $
2 .\"
3 .\" Copyright (c) 1980, 1993
4 .\"     The Regents of the University of California.  All rights reserved.
5 .\"
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
8 .\" are met:
9 .\" 1. Redistributions of source code must retain the above copyright
10 .\"    notice, this list of conditions and the following disclaimer.
11 .\" 2. Redistributions in binary form must reproduce the above copyright
12 .\"    notice, this list of conditions and the following disclaimer in the
13 .\"    documentation and/or other materials provided with the distribution.
14 .\" 3. Neither the name of the University nor the names of its contributors
15 .\"    may be used to endorse or promote products derived from this software
16 .\"    without specific prior written permission.
17 .\"
18 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
19 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
20 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
22 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
23 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
24 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
25 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
26 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
27 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" SUCH DAMAGE.
29 .\"
30 .\"     @(#)xstr.1      8.2 (Berkeley) 12/30/93
31 .\"
32 .Dd July 23, 2004
33 .Dt XSTR 1
34 .Os
35 .Sh NAME
36 .Nm xstr
37 .Nd "extract strings from C programs to implement shared strings"
38 .Sh SYNOPSIS
39 .Nm
40 .Op Fl cv
41 .Op Fl l Ar array
42 .Op Fl
43 .Op Ar
44 .Sh DESCRIPTION
45 .Nm
46 maintains a file
47 .Pa strings
48 into which strings in component parts of a large program are hashed.
49 These strings are replaced with references to this common area.
50 This serves to implement shared constant strings, most useful if they
51 are also read-only.
52 .Pp
53 Available options:
54 .Bl -tag -width XXlXarrayXX
55 .It Fl
56 .Nm
57 reads from the standard input.
58 .It Fl c
59 .Nm
60 will extract the strings from the C source
61 .Ar file
62 or the standard input
63 .Pq Fl ,
64 replacing
65 string references by expressions of the form (\*[Am]xstr[number])
66 for some number.
67 An appropriate declaration of
68 .Nm
69 is prepended to the file.
70 The resulting C text is placed in the file
71 .Pa x.c ,
72 to then be compiled.
73 The strings from this file are placed in the
74 .Pa strings
75 data base if they are not there already.
76 Repeated strings and strings which are suffixes of existing strings
77 do not cause changes to the data base.
78 .It Fl l Ar array
79 Specify the named array in program references to abstracted
80 strings.
81 The default array name is xstr.
82 .It Fl v
83 Be verbose.
84 .El
85 .Pp
86 After all components of a large program have been compiled, a file
87 .Pa xs.c
88 declaring the common
89 .Nm
90 space can be created by a command of the form:
91 .Pp
92 .Dl $ xstr
93 .Pp
94 The file
95 .Pa xs.c
96 should then be compiled and loaded with the rest
97 of the program.
98 If possible, the array can be made read-only (shared) saving
99 space and swap overhead.
102 can also be used on a single file.
103 The following command creates files
104 .Pa x.c
106 .Pa xs.c
107 as before, without using or affecting any
108 .Pa strings
109 file in the same directory:
111 .Dl $ xstr name
113 It may be useful to run
115 after the C preprocessor if any macro definitions yield strings
116 or if there is conditional code which contains strings
117 which may not, in fact, be needed.
118 An appropriate command sequence for running
120 after the C preprocessor is:
122 .Bd -literal -offset indent
123 $ cc \-E name.c | xstr \-c \-
124 $ cc \-c x.c
125 $ mv x.o name.o
129 does not touch the file
130 .Pa strings
131 unless new items are added, thus
132 .Xr make 1
133 can avoid remaking
134 .Pa xs.o
135 unless truly necessary.
136 .Sh FILES
137 .Bl -tag -width /tmp/xsxx* -compact
138 .It Pa strings
139 Data base of strings
140 .It Pa x.c
141 Massaged C source
142 .It Pa xs.c
143 C source for definition of array `xstr'
144 .It Pa /tmp/xs*
145 Temp file when `xstr name' doesn't touch
146 .Pa strings
148 .Sh SEE ALSO
149 .Xr mkstr 1
150 .Sh HISTORY
153 command appeared in
154 .Bx 3.0 .
155 .Sh BUGS
156 If a string is a suffix of another string in the data base,
157 but the shorter string is seen first by
159 both strings will be placed in the data base, when just
160 placing the longer one there will do.
163 does not parse the file properly so it does not know not to process:
164 .Bd -literal
165         char var[] = "const";
167 into:
168 .Bd -literal
169         char var[] = (\*[Am]xstr[N]);
172 These must be changed manually into an appropriate initialization for
173 the string, or use the following ugly hack.
175 Also,
177 cannot initialize structures and unions that contain strings.
178 Those can be fixed by changing from:
179 .Bd -literal
180         struct foo {
181                 int i;
182                 char buf[10];
183         } = {
184                 1, "foo"
185         };
188 .Bd -literal
189         struct foo {
190                 int i;
191                 char buf[10];
192         } = {
193                 1, { 'f', 'o', 'o', '\e0' }
194         };
197 The real problem in both cases above is that the compiler knows the size
198 of the literal constant so that it can perform the initialization required,
199 but when
201 changes the literal string to a pointer reference, the size information is
202 lost.
203 It would require a real parser to do this right, so the obvious solution is
204 to fix the program manually to compile, or even better rely on the compiler
205 and the linker to merge strings appropriately.
207 Finally,
209 is not very useful these days because most of the string merging is done
210 automatically by the compiler and the linker, provided that the strings
211 are identical and read-only.