Re: function portability documentation
Bruno Haible <[EMAIL PROTECTED]> writes: > Hi, > > Inspired by Paul Eggert's new chapter about "Portable C and C++ Programming", > I went out and collected portability notes and pitfall reminders for over > 200 among the 1116 POSIX functions. (Attached.) Thanks, this seems incredibly useful! Perhaps we can write a 'glint' (pun on gnulib-lint) tool that searches through source codes and prints out your warnings when a sub-optimal function is used (and the gnulib improvement isn't present)... I know I would have use for that. /Simon
function portability documentation
Hi,
Inspired by Paul Eggert's new chapter about "Portable C and C++ Programming",
I went out and collected portability notes and pitfall reminders for over
200 among the 1116 POSIX functions. (Attached.)
You will also notice that a section named "Function Portability" and with the
same purpose exists already under section "Library Functions" of the autoconf
manual, but that it is quite outdated (it speaks about HP-UX 9 and Solaris 9).
I propose to combine these two "Function Portability" sections.
Questions:
1) Where in the autoconf manual should this section go?
I think it should go into the new "Portable C and C++ Programming" chapter,
because the "Existing Tests" chapter deals primarily with tests already
present in autoconf - whereas for most of the known portability problems
we can only give some advice, but not an autoconf test that is perfect for
everyone.
2) Who should maintain this section in the future?
Why does the section currently have only 20 entries, when an up-to-date
list of portability problems has more than 200 entries? I think the answer
is that the autoconf maintainers are busy with autoconf, whereas the people
who write or maintain programs and deal with portability problems on a daily
basis gather on the bug-gnulib mailing list. On this background, I would
propose that the autoconf people "outsource" this manual section to the
gnulib project and include it as-is from the gnulib CVS. (The same way as
config.guess, standards.texi and other files come from elsewhere.)
Bruno
*** autoconf.texi.bak 2006-05-01 23:09:41.0 +0200
--- autoconf.texi 2006-05-22 02:34:30.0 +0200
***
*** 486,491
--- 486,492
* Null Pointers:: Properties of null pointers
* Buffer Overruns:: Subscript errors and the like
* Floating Point Portability:: Portable floating-point arithmetic
+ * Function Portability::Portable use of standard functions
* Exiting Portably::Exiting and the exit status
Manual Configuration
***
*** 14170,14175
--- 14171,14177
* Null Pointers:: Properties of null pointers
* Buffer Overruns:: Subscript errors and the like
* Floating Point Portability:: Portable floating-point arithmetic
+ * Function Portability::Portable use of standard functions
* Exiting Portably::Exiting and the exit status
@end menu
***
*** 14310,14315
--- 14312,15178
@uref{http://www.validlab.com/goldberg/paper.pdf, What Every Computer
Scientist Should Know About Floating-Point Arithmetic}.
+ @node Function Portability
+ @section Portability of Standard Functions
+ @cindex functions
+
+ Many standard library functions have portability limitations, although
+ they are specified in the
+ @uref{http://www.opengroup.org/susv3, Posix standard}. In this section,
+ we mention only functions that behave differently than specified; we don't
+ mention functions that are not implemented at all on some platforms, or
+ that are implemented but not declared on some platforms. Many of the
+ portability problems have a solution in @ref{Gnulib}.
+
+ @table @code
+ @item a64l
+ This function was not correctly implemented in glibc versions before 2.2.5.
+
+ @item accept
+ Some systems don't have a @code{socklen_t} type; in this case this function's
+ third argument type is @samp{int *}.
+
+ @item asctime
+ This function may overflow its internal buffer if an invalid year is passed.
+
+ @item asctime_r
+ This function may put more than 26 bytes into the argument buffer if an
+ invalid year is passed.
+
+ @item basename
+ glibc has two different functions @code{basename}: the POSIX version and
+ the GNU version.
+
+ @code{basename} assumes file names in POSIX syntax; it does not with file
+ names in Windows syntax.
+
+ @item bcmp
+ This function is marked as ``legacy'' in POSIX. Better use @code{memcmp}
+ instead.
+
+ @item bcopy
+ This function is marked as ``legacy'' in POSIX. Better use @code{memcpy}
+ or @code{memmove} instead.
+
+ @item btowc
+ On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
+ accomodate all Unicode characters.
+
+ @item bzero
+ This function is marked as ``legacy'' in POSIX. Better use @code{memset}
+ instead.
+
+ @item chown
+ When applied to a symbolic link, some implementations don't dereference
+ the symlink, i.e. they behave like @code{lchown}.
+
+ @item cproj
+ @itemx cprojf
+ @itemx cprojl
+ The glibc implementation is or was broken.
+
+ @item creat
+ On Windows, this function returns a file handle in @code{O_TEXT} mode. If you
+ need a file handle in @code{O_BINARY} mode, you need to use the function
+ @code{open} instead.
+
+ On platforms where @code{off_t} is a 32-bit type, @code{creat} may not work
+ correctly to create files larger than 2 GB. The fix is to use the
+ @code{AC_SYS_LARGEFILE} macro.
+
+ @item ctime
+ This function may overflow
Re: function portability documentation
Hi Bruno,
* Bruno Haible wrote on Mon, May 22, 2006 at 02:13:52PM CEST:
>
> 2) Who should maintain this section in the future?
>
> Why does the section currently have only 20 entries, when an up-to-date
> list of portability problems has more than 200 entries? I think the answer
> is that the autoconf maintainers are busy with autoconf, whereas the people
> who write or maintain programs and deal with portability problems on a daily
> basis gather on the bug-gnulib mailing list.
Hmm, I think I'm not the right person to judge this, but I do think
putting it in the Autoconf manual is a great idea.
I'm easier on technical comments; if we want this in Autoconf-2.60, it
should be stabilized quickly, so here we go, quickly:
- Should the entries be indexed? I would prefer so. You can probably
take your patch and run the resulting autoconf.texi through a sed script
similar to this one:
sed '14312,15178{
/@item/{
p
s/[EMAIL PROTECTED],1\} \(.*\)/@prindex @code{\1}/
}
}'
to produce reasonable indexing, after adjusting the line numbers a bit.
(This script is not portable, but works with GNU sed.)
- It would probably add to the long-term maintainability if the *printf
and similar families of functions would be treated in one place only.
This isn't too important now, though.
- Then, for uniformity with the rest of the manual, please
s/POSIX/Posix/
s/\(BSD\|GNU\|IRIX\)/@acronym{\1}/
- The existing section on function portability should be merged with
this one in a suitable way.
More comments inline. Please take them with a grain of salt, from a
non-native speaker, and apologies for their terse-ness.
> + @code{basename} assumes file names in POSIX syntax; it does not with file
> + names in Windows syntax.
I'd prefer a verb in the second half of the sentence.
> + @item dirname
> + @code{dirname} assumes file names in POSIX syntax; it does not with file
> + names in Windows syntax.
Likewise.
> + @item dlopen
> + If the file name argument is not absolute, the file is searched for. The
> + search algorithm is system specific.
I think it's system-specific.
> + @item dlsym
> + The visibility of symbols loaded in dependent shared libraries or present
> + in the main executable is system dependent.
Likewise, system-dependent. Several instances.
> + @item errno
> + On Windows, the socket functions don't set @code{errno}; their error code is
> + available through @code{WSAGetLastError()} instead.
A recent change to GCS suggests not using the parentheses to denote
a function; reserve that for actual function calls instead.
> + @item fnmatch
> + This function is broken in some version of Solaris or glibc.
Shouldn't this be `and' instead of `or'?
> + @item fopen
> + On Windows systems (excluding Cygwin), this function does not set
> @code{errno}
> + upon failure.
> +
> + On Windows, this function returns a file stream in "text" mode by default;
FWIW, I'd just write text mode.
> + this means that it translates '\n' to CR/LF by default. Use the "b" flag
> + if you need reliable binary I/O.
Please use @samp{\n}, and @samp{"b"}; more generally, I'd put most
double-quoted values in the section in @samp{}, or @code{} when they
specify code literals, they look nicer that way in the DVI output.
> + @item fprintf
> + On NetBSD and Windows, this function doesn't support format directives that
> + access arguments in an arbitrary order, such as "%2$s". The fix is to
> include
Likewise. Several instances.
> + @file{} from GNU gettext; it redefines this function so that it
> is
> + POSIX compliant.
Wouldn't @file{libintl.h}, or `The fix is to @samp{#include }'
look nicer? Several instances.
> + @item fstat
> + On platforms where @code{off_t} is a 32-bit type, @code{stat} may not report
> + correctly the size of files or block devices larger than 2 GB. The fix is
> to
> + use the @code{AC_SYS_LARGEFILE} macro.
s/report correctly/correctly report/
If integrated into Autoconf, it'd be nice to cross-reference
AC_SYS_LARGEFILE. Cross-referencing could be a problem with
"inclusion from Gnulib CVS".
> + @item getgroups
> + On Ultrix 4.3, @code{getgroups (0, 0)} always fails. See macro
> + @samp{AC_FUNC_GETGROUPS}.
Likewise.
> + @item getopt
> + The glibc implementation of @code{getopt} by default allows mixing option
> and
> + non-option arguments on the command line in any order. Other
> implementations,
> + such as the one in Cygwin, enfore strict POSIX compliance: they require that
s/enfore/enforce/; I'd move `by default' to the beginning or end of the
sentence.
> + the option arguments precede the non-option arguments. This is something to
> + watch out in your program's testsuite.
> + When @code{iconv} encounters an input character that is valid but that can
> + not be converted to the output character set, glibc's and GNU libiconv's
> + @code{iconv} stop the conversion. Some other implementations put an
> + implementation-defined
Re: function portability documentation
Bruno, that's great work. I did some proofreading and found some
minor things to point out.
Bruno Haible <[EMAIL PROTECTED]> writes:
> + @code{basename} assumes file names in POSIX syntax; it does not with file
> + names in Windows syntax.
"...does not" work "with file..."
> + @item btowc
> + On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
> + accomodate all Unicode characters.
"accommodate"
> + @item chown
> + When applied to a symbolic link, some implementations don't dereference
> + the symlink, i.e. they behave like @code{lchown}.
i.e.@:
> + @item dirname
> + @code{dirname} assumes file names in POSIX syntax; it does not with file
> + names in Windows syntax.
"...does not" work "with file..."
> + @item fgetwc
> + @itemx fgetws
> + On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
> + accomodate all Unicode characters.
"accommodate"
> + @item fopen
> + On Windows systems (excluding Cygwin), this function does not set
> @code{errno}
> + upon failure.
> +
> + On Windows, this function returns a file stream in "text" mode by default;
> + this means that it translates '\n' to CR/LF by default. Use the "b" flag
> + if you need reliable binary I/O.
"text" => ``text''
Should "b" be @samp{b}?
> + @item fprintf
> + On NetBSD and Windows, this function doesn't support format directives that
> + access arguments in an arbitrary order, such as "%2$s". The fix is to
> include
> + @file{} from GNU gettext; it redefines this function so that it
> is
> + POSIX compliant.
> +
> + On Windows, this function doesn't support the @code{'} flag and the
> @code{hh},
> + @code{ll}, @code{j}, @code{t}, @code{z} size specifiers.
The Texinfo manual says @samp{} should be used for single
characters, for what it's worth. Dunno if you care.
> + @item fputwc
> + @itemx fputws
> + On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
> + accomodate all Unicode characters.
"accommodate"
Several other misspellings of this same word that I won't point
out separately.
> + @item getopt
> + The glibc implementation of @code{getopt} by default allows mixing option
> and
> + non-option arguments on the command line in any order. Other
> implementations,
> + such as the one in Cygwin, enfore strict POSIX compliance: they require that
> + the option arguments precede the non-option arguments. This is something to
> + watch out in your program's testsuite.
enfore => enforce
Is "testsuite" one word?
> + @item getpeername
> + Some systems don't have a @code{socklen_t} type; in this case this
> function's
> + third argument type is @samp{int *}.
Gnulib has a socklen module that should perhaps be mentioned here
(and in other references to socklen_t).
> + @item getsockopt
> + Some systems don't have a @code{socklen_t} type; in this case this
> function's
> + fifth argument type is @samp{int *}.
> +
> + Many socket options are not available on all systems.
Is it worth listing which socket options are specified in
the Unix standards, or can even those not be depended upon?
> + @item iconv
> + This function was not correctly implemented in glibc versions before 2.2.
> +
> + When @code{iconv} encounters an input character that is valid but that can
> + not be converted to the output character set, glibc's and GNU libiconv's
> + @code{iconv} stop the conversion. Some other implementations put an
> + implementation-defined character in the output buffer.
"can not" => "cannot"
> + @item iconv_open
> + The set of supported encodings and conversions is system dependent.
> +
> + @item index
> + This function is marked as ``legacy'' in POSIX. Better use @code{strchr}
> + instead.
> +
> + @item inet_addr
> + On some old systems, this function returns a @samp{struct in_addr} rather
> + than a scalar type such as @samp{unsigned int} or @samp{unsigned long}.
> +
> + @item ioctl
> + Most @code{ioctl} requests are platform and hardware specific.
> +
> + @item isatty
> + On Windows, @code{isatty} also returns true for character devices such as
> + "NUL".
Should "NUL" be @file{NUL}?
> + @item mkdir
> + When the argument ends in a slash, the function call fails on some systems.
> +
> + On Windows systems (excluding Cygwin), this function is called @code{_mkdir}
> + and takes only one argument. The fix is to define a macro like this:
> + @smallexample
> + #define mkdir ((int (*)()) _mkdir)
> + @end smallexample
Is that better than this?
#define mkdir(a,b,c) _mkdir(a,b)
> + @item mktime
> + Some implementations of @code{mktime} may go into an endless loop.
Ouch. Is there a workaround?
> + @item nanosleep
This entry is empty.
> + @item open
> + On Windows, this function returns a file handle in @code{O_TEXT} mode by
> + default; this means that it translates '\n' to CR/LF by default. Use the
> + @code{O_BINARY} flag if you need reliable binary I/O.
It seems slightly odd to mix C and character name notation.
Perhaps "translates '\n' to
Re: function portability documentation
Ralf Wildenhues wrote:
> so here we go, quickly:
Thanks, Ralf, for proofreading. I've integrated many of your remarks.
> - Should the entries be indexed? I would prefer so.
Yes, certainly. Probably this is also a good occasion to split the
"program index" and the "function / header index". IMO they should be
separate, because they belong to two different worlds (shell vs. C).
> - It would probably add to the long-term maintainability if the *printf
> and similar families of functions would be treated in one place only.
> This isn't too important now, though.
The main ordering is alphabetically; I cannot see any other reasonable sort
criterion. But you are right, if we want to expand on the printf or on the
wchar_t topic, it's probably good to add a subsection for each of these
two topics, to which we can then refer in each function's notes.
> - Then, for uniformity with the rest of the manual, please
>s/POSIX/Posix/
POSIX is an acronym (Portable Operating System Interface for UniX) and
should therefore IMO be written in upper case.
>s/\(BSD\|GNU\|IRIX\)/@acronym{\1}/
I'm sorry, but have you seen how it looks in autoconf.dvi when @acronym
is used? Awful. No font change is better than this one.
> > The + search algorithm is system specific.
>
> I think it's system-specific.
Not sure. You find both writings frequently on the web.
> > code is + available through @code{WSAGetLastError()} instead.
>
> A recent change to GCS suggests not using the parentheses to denote
> a function; reserve that for actual function calls instead.
Here I mean the actual function call. errno needs to be conditionally replaced
with WSAGetLastError().
> > + @item fnmatch
> > + This function is broken in some version of Solaris or glibc.
>
> Shouldn't this be `and' instead of `or'?
I don't know. The gnulib macro wasn't clear enough to me. I hope Paul knows
more about it.
> > + this means that it translates '\n' to CR/LF by default. Use the "b"
> > flag + if you need reliable binary I/O.
>
> Please use @samp{\n}, and @samp{"b"}; more generally, I'd put most
> double-quoted values in the section in @samp{}, or @code{} when they
> specify code literals, they look nicer that way in the DVI output.
I'll put them in @code.
> > + @file{} from GNU gettext; it redefines this function so that
> > it is + POSIX compliant.
>
> Wouldn't @file{libintl.h}, or `The fix is to @samp{#include }'
> look nicer? Several instances.
Hmm, #include is not an English verb...
> it'd be nice to cross-reference AC_SYS_LARGEFILE.
Yes. How do I write a reference to a macro definition inside an info node
(_not_ to the info node that contains it)? The index apparently has such
references, but how to I write them in texinfo?
> It's be good to answer these questions before it goes in.
Yes. I hope Paul Eggert knows these.
> > + @item Integer types smaller than @samp{int}.
>
> Would `Integer types with a lower conversion rank than that of @samp{int}.'
> be better? (As in: even if, on your system, short int and int have the
> same representation
Such systems are outside the scope of this section; they are not GNU porting
targets.
> > + @item mkdir
> > + When the argument ends in a slash, the function call fails on some
> > systems.
>
> Do we know which?
We need to add more details afterwards. This is just a beginning.
> Refer to AC_FUNC_MMAP?
AC_FUNC_MMAP is the answer only for a specific use case of mmap. There are
many others.
> > + @item nanosleep
>
> TODO? :-)
Yes :-)
Bruno
Re: [bug-gnulib] Re: function portability documentation
Ben Pfaff wrote:
> I did some proofreading and found some minor things to point out.
Thanks. I'm fixing most of these.
> Should "b" be @samp{b}?
@code{"b"} is better here: the 'b' must be part of C string.
> > + On Windows, this function doesn't support the @code{'} flag and the
> > @code{hh}, + @code{ll}, @code{j}, @code{t}, @code{z} size specifiers.
>
> The Texinfo manual says @samp{} should be used for single
> characters, for what it's worth. Dunno if you care.
@samp{'} looks too awful.
> Is "testsuite" one word?
Google comparison: "testsuite" -> 32 million hits, "test suite" -> 26 million.
So it seems ok.
> > + @item open
> > + On Windows, this function returns a file handle in @code{O_TEXT} mode
> > by + default; this means that it translates '\n' to CR/LF by default.
> > Use the + @code{O_BINARY} flag if you need reliable binary I/O.
>
> It seems slightly odd to mix C and character name notation.
Well, it's talking about C character names on one hand and byte values on the
other hand.
> Perhaps "translates '\n' to '\r\n'" or "adds a carriage return
> before every new-line"?
Well, that's not actually what it does. The '\n' and the CR/LF are on different
conceptual levels.
> > + @item poll
> > + On MacOS X 10.4.0 and AIX 5.3, this function doesn't work on special
> > files + like @file{/dev/null} and ttys like @file{/dev/tty}.
>
> How does it fail?
Too weird, you don't want to know ;-)
> Gnulib has a socklen module that should perhaps be mentioned here
> (and in other references to socklen_t).
> ...
> Is it worth listing which socket options are specified in
> the Unix standards, or can even those not be depended upon?
> ...
> It would be nice to be more specific, if possible naming kernel
> or glibc versions as prerequisites for correct behavior.
> ...
> You could mention the Gnulib stdarg module here.
Good points. In this first draft, I limited myself to listing the problems.
Showing solutions comes afterwards. I think we can discuss these things on
bug-gnulib. It's too many topics to discuss all at once, though :-)
Bruno
Re: [bug-gnulib] Re: nanosleep module and mingw32
On Sun, 21. May 2006, 21:27:15 -0700, Paul Eggert wrote: > > No, unfortunately it does not, because the target system does not have a > > nanosleep function. > > OK. Do the other parts of the patch (e.g., the HAVE_SYS_SELECT_H, > TIME_WITH_SYS_TIME, etc.) address the problem? If not, what problems > do you encounter with the latest version? (We prefer solutions that > do not have Windows-specific ifdefs sprinkled all over the place.) With the latest version, I get the compiler warning nanosleep.c: In function `my_usleep': nanosleep.c:95: warning: implicit declaration of function `select' and the linker error ../gnulib/libgnu.a(nanosleep.o): In function `my_usleep':\ /home/martin/projects/mpop/mpop/gnulib/nanosleep.c:95:\ undefined reference to `_select' Martin
Re: function portability documentation
Thanks for that suggestion and the work in generating that nice patch.
One general comment is that there is a lot of duplicate text that
perhaps could simply be replaced by an index. E.g., instead of this:
@item btowc
On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
accomodate all Unicode characters.
...
@item fgetwc
@itemx fgetws
On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
accomodate all Unicode characters.
...
@item fputwc
@itemx fputws
On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
accomodate all Unicode characters.
...
@item fwide
On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
accomodate all Unicode characters.
...
(and on and on -- there are lots of these), it would be better to
simply have a paragraph like this:
On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
accomodate all Unicode characters. This affects the following functions:
btowc fgetwc fputwc fputws fwide ...
and then create an index of all the functions that have portability
implications, and plant entries for btowc etc. in this index. Or
perhaps we could reuse one of the existing Autoconf indices for this
purpose.
Using an index would make the main text shorter and much easier to
read, and the index would let people look up info about each function
as needed.
Re: gettimeofday() for Win32
On Sun, 09. Oct 2005, 08:56:50 +0200, Ralf Wildenhues wrote:
> If I may, a couple of comments on the code:
Thanks! I'm sorry that it took me so long to respond to this.
(The original thread is archived here:
http://www.mail-archive.com/bug-gnulib%40gnu.org/msg00823.html )
I updated the patch according to your comments. I'd be happy if it would
be reconsidered for inclusion.
Martin
diff -uNr gnulib/lib/gettimeofday.c gnulib-gettimeofday-2/lib/gettimeofday.c
--- gnulib/lib/gettimeofday.c 2005-09-19 19:28:14.0 +0200
+++ gnulib-gettimeofday-2/lib/gettimeofday.c2006-05-22 22:03:19.0
+0200
@@ -1,8 +1,9 @@
-/* Work around the bug in some systems whereby gettimeofday clobbers the
- static buffer that localtime uses for it's return value. The gettimeofday
+/* Provide gettimeofday for systems that don't have it, or,
+ work around the bug in some systems whereby gettimeofday clobbers the
+ static buffer that localtime uses for its return value. The gettimeofday
function from Mac OS X 10.0.4, i.e. Darwin 1.3.7 has this problem.
The tzset replacement is necessary for at least Solaris 2.5, 2.5.1, and 2.6.
- Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
+ Copyright (C) 2001, 2002, 2003, 2006 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
@@ -46,7 +47,13 @@
#include
+#if HAVE_SYS_TIMEB_H
+#include
+#endif
+
+#if GETTIMEOFDAY_CLOBBERS_LOCALTIME
static struct tm *localtime_buffer_addr;
+#endif
/* This is a wrapper for localtime. It is used only on systems for which
gettimeofday clobbers the static buffer used for localtime's result.
@@ -54,6 +61,7 @@
On the first call, record the address of the static buffer that
localtime uses for its result. */
+#if GETTIMEOFDAY_CLOBBERS_LOCALTIME
struct tm *
rpl_localtime (const time_t *timep)
{
@@ -64,8 +72,10 @@
return tm;
}
+#endif
/* Same as above, since gmtime and localtime use the same buffer. */
+#if GETTIMEOFDAY_CLOBBERS_LOCALTIME
struct tm *
rpl_gmtime (const time_t *timep)
{
@@ -76,16 +86,20 @@
return tm;
}
+#endif
-/* This is a wrapper for gettimeofday. It is used only on systems for which
- gettimeofday clobbers the static buffer used for localtime's result.
-
- Save and restore the contents of the buffer used for localtime's result
- around the call to gettimeofday. */
+/* This is a wrapper for gettimeofday.
+ It is used only on systems that lack this function, or for whose
+ implementation of this function causes problems. */
int
-rpl_gettimeofday (struct timeval *tv, struct timezone *tz)
+rpl_gettimeofday (struct timeval *restrict tv, void *restrict tz)
{
+#if HAVE_GETTIMEOFDAY
+# if GETTIMEOFDAY_CLOBBERS_LOCALTIME
+
+ /* Save and restore the contents of the buffer used for localtime's result
+ around the call to gettimeofday. */
struct tm save;
int result;
@@ -100,12 +114,39 @@
*localtime_buffer_addr = save;
return result;
+
+# endif
+#else
+# if HAVE__FTIME
+
+ struct _timeb timebuf;
+
+ _ftime (&timebuf);
+ tv->tv_sec = timebuf.time;
+ tv->tv_usec = timebuf.millitm * 1000;
+
+ return 0;
+
+# else
+
+ time_t t = time (NULL);
+
+ if (t == (time_t) -1)
+return -1;
+ tv->tv_sec = t;
+ tv->tv_usec = 0;
+
+ return 0;
+
+# endif
+#endif
}
/* This is a wrapper for tzset. It is used only on systems for which
tzset may clobber the static buffer used for localtime's result.
Save and restore the contents of the buffer used for localtime's
result around the call to tzset. */
+#if GETTIMEOFDAY_CLOBBERS_LOCALTIME
void
rpl_tzset (void)
{
@@ -121,3 +162,4 @@
tzset ();
*localtime_buffer_addr = save;
}
+#endif
diff -uNr gnulib/lib/gettimeofday.h gnulib-gettimeofday-2/lib/gettimeofday.h
--- gnulib/lib/gettimeofday.h 1970-01-01 01:00:00.0 +0100
+++ gnulib-gettimeofday-2/lib/gettimeofday.h2006-05-22 22:03:25.0
+0200
@@ -0,0 +1,39 @@
+/* Provide gettimeofday for systems that don't have it, or
+ work around the bug in some systems whereby gettimeofday clobbers the
+ static buffer that localtime uses for its return value. The gettimeofday
+ function from Mac OS X 10.0.4, i.e. Darwin 1.3.7 has this problem.
+ The tzset replacement is necessary for at least Solaris 2.5, 2.5.1, and 2.6.
+ Copyright (C) 2001, 2002, 2003, 2006 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 deta
