summaryrefslogtreecommitdiff
path: root/README
blob: 221aa9f829e2a49dc21d86adbbaf59b0e272c4c5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
GNULib
======

GNULib is intended to be the canonical source for most of the important
"Portability" files for GNU projects.

While portability is not one of our primary goals, it has helped
introduce many people to the GNU system, and is worthwhile when it can
be achieved at a low cost.  This collection helps lower that cost.

There are three directories that contain all of the files:

gpl/   - Any source files licensed under the GNU General Public License
lgpl/  - Any source files licensed under the GNU Lesser GPL
doc/   - Any documents that may be nice to have in applications.  This
includes such files as 'COPYING, COPYING.LIB, etc.'

Contributing to GNULib
======================

All software here is Copyright (c) Free Software Foundation - you need
to have filled out an assignment form for a project that uses the
module for that contribution to be accepted here.

If you have a piece of code that you would like to contribute, please
email bug-gnulib@gnu.org.  We will add you to the maintainers list.

Generally we are looking for files that fulfill at least one of the
following requirements:

    * If your .c and .h files define functions that are broken or
missing on some other system, we should be able to include it.

    * If your functions remove arbitrary limits from existing
functions (either under the same name, or as a slightly different
name), we should be able to include it.

If your functions define completely new but rarely used functionality,
you should probably consider packaging it as a separate library.

How to add a new module
-----------------------

* Add the header files and source files to lib/.
* If the module needs configure-time checks, write an autoconf
  macro for it in m4/<module>.m4. See m4/README for details.
* Write a module description modules/<module>, based on modules/TEMPLATE.
* Add the module to the list in MODULES.html.sh.

You can test that a module builds correctly with:
  $ ./gnulib-tool --create-testdir --dir=/tmp/testdir module1 ... moduleN
  $ cd /tmp/testdir
  $ ./configure && make

Other things:
* Check the license and copyright year of headers.
* Check that the source code follows the GNU coding standards;
  see <http://www.gnu.org/prep/standards>.
* Add source files to config/srclist* if they are identical to upstream
  and should be upgraded in gnulib whenever the upstream source changes.
* Include header files in source files to verify the function prototypes.
* Make sure a replacement function doesn't cause warnings or clashes on
  systems that have the function.
* Autoconf functions can use gl_* prefix. The AC_* prefix is for
  autoconf internal functions.
* Build files only if they are needed on a platform.  Look at the
  alloca and fnmatch modules for how to achieve this.  If for some
  reason you cannot do this, and you have a .c file that leads to an
  empty .o file on some platforms (through some big #if around all the
  code), then ensure that the compilation unit is not empty after
  preprocessing.  One way to do this is to #include <stddef.h> or
  <stdio.h> before the big #if.

Portability guidelines
----------------------

GNULib code is intended to be portable to a wide variety of platforms,
not just GNU platforms.

Many GNULib modules exist so that applications need not worry about
undesirable variability in implementations.  For example, an
application that uses the 'malloc' module need not worry about (malloc
(0)) returning NULL on some Standard C platforms; and 'time_r' users
need not worry about localtime_r returning int (not char *) on some
platforms that predate POSIX 1003.1-2001.

Originally much of the GNULib code was portable to ancient hosts like
4.2BSD, but it is a maintenance hassle to maintain compatibility with
unused hosts, so currently we assume at least a freestanding C89
compiler, possibly operating with a C library that predates C89.  The
oldest environment currently ported to is probably SunOS 4 + GCC 1.x,
though we haven't tested this exact combination.  SunOS 4 last shipped
on 1998-09-30, and Sun dropped support for it on 2003-10-01, so at
some point we may start assuming a C89 library as well.

Because we assume a freestanding C89 compiler, GNULib code can include
<float.h>, <limits.h>, <stdarg.h>, and <stddef.h> unconditionally.  It
can also include hosted headers like <errno.h> that were present in
Unix Version 7 and are thus widely available.  Similarly, many modules
include <sys/types.h> even though it's not even in C99; that's OK
since <sys/types.h> has been around nearly forever.  <string.h> and
<stdlib.h> were not in Unix Version 7, so they weren't universally
available on ancient hosts, but they are both in SunOS 4 (the oldest
platform still in relatively-common use) so GNULib assumes them now.

Even if the include files exist, they may not conform to C89.
However, GCC has a "fixincludes" script that attempts to fix most
C89-conformance problems.  So GNULib currently assumes include files
largely conform to C89 or better.  People still using ancient hosts
should use fixincludes or fix their include files manually.

Even if the include files conform to C89, the library itself may not.
For example, SunOS 4's (free (NULL)) can dump core, so GNULib code
must avoid freeing a null pointer, even though C89 allows it.
You can work around some of these problems by requiring the relevant
modules, e.g., the GNULib 'free' module supplies a conforming 'free'.

The GNU coding standards allow one departure from strict C99: GNULib
code can assume that standard internal types like size_t are no wider
than 'long'.  POSIX 1003.1-2001 and the GNU coding standards both
require 'int' to be at least 32 bits wide, so GNULib code assumes this
as well.  GNULib code makes the following additional assumptions:

 * Signed integer arithmetic is two's complement, without runtime
   overflow checking.  This is the traditional behavior, and is
   supported by C99 implementations that conform to ISO/IEC 10967-1
   (LIA-1) and that define signed integer types as being modulo.

 * There are no "holes" in integer values: all the bits of an integer
   contribute to its value in the usual way.

 * If two nonoverlapping objects have sizes S and T represented as
   size_t values, then S + T cannot overflow.  This assumption is true
   for all practical hosts with flat address spaces, but it is not
   always true for hosts with segmented address spaces.

 * If an existing object has size S, and if T is sufficiently small
   (e.g., 8 KiB), then S + T cannot overflow.  Overflow in this case
   would mean that the rest of your program fits into T bytes, which
   can't happen in realistic flat-address-space hosts.

 * Objects with all bits zero are treated as 0 or NULL.  For example,
   memset (A, 0, sizeof A) initializes an array A of pointers to NULL.

 * Adding zero to a null pointer does not change the pointer.
   For example, 0 + (char *) NULL == (char *) NULL.

The above assumptions are not required by the C or POSIX standards but
hold on all practical porting targets that we're familiar with.  If
you have a porting target where these assumptions are not true, we'd
appreciate hearing of any fixes.  We need fixes that do not increase
runtime overhead on standard hosts and that are relatively easy to
maintain.

With the above caveats, GNULib code should port without problem to new
hosts, e.g., hosts conforming to C99 or to recent POSIX standards.
Hence GNULib code should avoid using constructs (e.g., undeclared
functions return 'int') that do not conform to C99.

High Quality
============

We will be developing a testsuite for these applications.  The goal is
to have a 100% firm interface so that maintainers can feel free to
update to the code in CVS at *any* time and know that their
application will not break.  This means that before any change can be
committed to the repository, a test suite program must be produced
that exposes the bug for regression testing.  All experimental work
should be done on branches to help promote this.

CVS
===

GNULib is available for anonymous checkout.  In any Bourne-shell the
following should work:

$ cvs -d :pserver:anoncvs@cvs.gnu.org:/cvsroot/gnulib login
(Just hit Enter or Return when prompt for a password)
$ cvs -d :pserver:anoncvs@cvs.gnu.org:/cvsroot/gnulib checkout gnulib


-----

Copyright (C) 2001, 2003, 2004 Free Software Foundation, Inc.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */