[PATCH] tests: port test-fdutimensat.c to Solaris 8
* tests/test-fdutimensat.c (do_fdutimens): Don't assume
fdutimensat works with a nonnegative fd and AT_SYMLINK_NOFOLLOW.
On Solaris 8, it fails with errno == ENOSYS, because there is no
futimens (so it can't use the fd), and there is no lutimens (so it
can't implement AT_SYMLINK_NOFOLLOW on symlinks).
---
ChangeLog|7 +++
tests/test-fdutimensat.c |7 ++-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f53bcb4..97909fe 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
2010-12-23 Paul Eggert egg...@cs.ucla.edu
+ tests: port test-fdutimensat.c to Solaris 8
+ * tests/test-fdutimensat.c (do_fdutimens): Don't assume
+ fdutimensat works with a nonnegative fd and AT_SYMLINK_NOFOLLOW.
+ On Solaris 8, it fails with errno == ENOSYS, because there is no
+ futimens (so it can't use the fd), and there is no lutimens (so it
+ can't implement AT_SYMLINK_NOFOLLOW on symlinks).
+
vsnprintf: make more consistent with snprintf; doc fixes
* doc/posix-functions/snprintf.texi (snprintf): The workaround for
diff --git a/tests/test-fdutimensat.c b/tests/test-fdutimensat.c
index d94667a..9f66cc6 100644
--- a/tests/test-fdutimensat.c
+++ b/tests/test-fdutimensat.c
@@ -48,12 +48,17 @@ static int
do_fdutimens (char const *name, struct timespec const times[2])
{
int result;
+ int nofollow_result;
+ int nofollow_errno;
int fd = openat (dfd, name, O_WRONLY);
if (fd 0)
fd = openat (dfd, name, O_RDONLY);
errno = 0;
+ nofollow_result = fdutimensat (fd, dfd, name, times, AT_SYMLINK_NOFOLLOW);
+ nofollow_errno = errno;
result = fdutimensat (fd, dfd, name, times, 0);
- ASSERT (fdutimensat (fd, dfd, name, times, AT_SYMLINK_NOFOLLOW) == result);
+ ASSERT (result == nofollow_result
+ || (nofollow_result == -1 nofollow_errno == ENOSYS));
if (0 = fd)
{
int saved_errno = errno;
--
1.7.2
Re: [PATCH] doc: document Solaris printf bug with large float precisions
Paul Eggert egg...@cs.ucla.edu writes:
Here's a simpler test case that illustrates the Solaris bug,
in case there's anybody here who can get bug fixes
into Solaris:
#include stdio.h
int
main (void)
{
char buf[1000];
int n = snprintf (buf, sizeof buf, %.511f, 1.0);
printf (%d %s\n, n, buf);
return 0;
}
This prints 513 0.0 rather than the correct 513 1.0.
Wouldn't it make sense to add a self-test for this, which would fail on
all other platforms, but on Solaris, return -77 to cause a SKIP?
Possibly also print a message with a link to this thread. That way,
people building on Solaris will notice the issue and someone may
eventually get it fixed upstream.
If there are no objections, I'll write up a self-test.
/Simon
Re: signal.h on HP-NonStop
Joachim Schmitz wrote: The only SA_something Macros I can find are SA_DATA_SITE in sys/socket.h, most probably unrelated, and SA_NOCLDSTOP and SA_RESERVED_31 in signal.h, and nothing that looks remotely like a replacement, signal.h attached Thanks for looking into this. So the best choice is to accept the fact that SA_RESETHAND and SA_RESTART are missing. I'm applying this: 2010-12-24 Bruno Haible br...@clisp.org sigaction tests: Allow missing SA_RESETHAND and SA_RESTART. * tests/test-sigaction.c (SA_RESETHAND): Fall back to 0. (SA_RESTART): Likewise. Reported by Joachim Schmitz j...@schmitz-digital.de. --- tests/test-sigaction.c.orig Fri Dec 24 11:04:09 2010 +++ tests/test-sigaction.c Fri Dec 24 10:59:45 2010 @@ -34,6 +34,12 @@ #ifndef SA_ONSTACK # define SA_ONSTACK 0 #endif +#ifndef SA_RESETHAND +# define SA_RESETHAND 0 +#endif +#ifndef SA_RESTART +# define SA_RESTART 0 +#endif #ifndef SA_SIGINFO # define SA_SIGINFO 0 #endif
Re: rename, renameat test failures on OSF/1
Hi Eric, -ASSERT (errno == EINVAL || errno == EBUSY); +ASSERT (errno == EINVAL || errno == EBUSY || errno == EEXIST); The patch to relax the testsuite looks okay to me; we're already allowing other non-standard errno values here, so no one has complained about it causing an actual problem in portability. Thanks for the review. Jim did not speak up against it yesterday. So I'm committing the patch. Bruno
Re: signal.h on HP-NonStop
Joachim Schmitz wrote:
OK, the highest number for any SIGsomething is 31, so NSIG should really be
32.
Thanks for this info. I'm adding a definition of NSIG for your platform.
2010-12-24 Bruno Haible br...@clisp.org
signal: Define NSIG.
* lib/signal.in.h (NSIG): Define to 32 on NonStop Kernel.
* tests/test-signal.c (nsig): New variable.
Reported by Joachim Schmitz j...@schmitz-digital.de.
--- lib/signal.in.h.origFri Dec 24 11:00:53 2010
+++ lib/signal.in.h Fri Dec 24 10:56:42 2010
@@ -72,6 +72,14 @@
#endif
+/* Maximum signal number + 1. */
+#ifndef NSIG
+# if defined __TANDEM
+# define NSIG 32
+# endif
+#endif
+
+
#if @GNULIB_SIGPROCMASK@
# if !...@have_posix_signalblocking@
--- tests/test-signal.c.origFri Dec 24 11:00:53 2010
+++ tests/test-signal.c Fri Dec 24 10:51:26 2010
@@ -35,6 +35,9 @@
#endif
} s;
+/* Check that NSIG is defined. */
+int nsig = NSIG;
+
int
main (void)
{
Re: rename, renameat test failures on OSF/1
Bruno Haible wrote: Hi Eric, -ASSERT (errno == EINVAL || errno == EBUSY); +ASSERT (errno == EINVAL || errno == EBUSY || errno == EEXIST); The patch to relax the testsuite looks okay to me; we're already allowing other non-standard errno values here, so no one has complained about it causing an actual problem in portability. Thanks for the review. Jim did not speak up against it yesterday. So I'm committing the patch. Yes, that looked fine to me, too. Thanks.
Re: [PATCH] doc: document Solaris printf bug with large float precisions
Hello Paul,
This prints 513 0.0 rather than the correct 513 1.0.
Indeed. I reproduce on Solaris 10/SPARC. On Solaris 10/x86, the result is
simply a SIGSEGV.
When I build a testdir for 'snprintf-posix', the results are:
- On Solaris 10/x86:
checking whether printf supports large precisions... no
checking whether printf survives out-of-memory conditions... no
REPLACE_SNPRINTF is 1.
All tests pass.
- On Solaris 10/sparc:
checking whether printf supports large precisions... yes
checking whether printf survives out-of-memory conditions... yes
REPLACE_SNPRINTF is 1.
test-snprintf-posix fails:
test-snprintf-posix.h:3039: assertion failed
bash: line 5: 2924 Abort (core dumped) EXEEXT=''
srcdir='.' MAKE='make' ${dir}$tst
FAIL: test-snprintf-posix
So the existing test whether printf supports large precisions was incomplete.
I'm integrating your test case, so that configure will now say no
on both Solaris 10/x86 and Solaris 10/sparc.
doc/posix-functions/dprintf.texi (dprintf):
doc/posix-functions/vdprintf.texi (vdprintf):
You did not need to modify these files. Solaris does not have dprintf and
vdprintf.
I'll check in this fix:
2010-12-24 Bruno Haible br...@clisp.org
*printf: Detect large precisions bug on Solaris 10/SPARC.
* m4/printf.m4 (gl_PRINTF_PRECISION): Add one more test code, provided
by Paul Eggert.
* tests/test-snprintf-posix.h (test_function): Add this test code here
too.
* tests/test-sprintf-posix.h (test_function): Likewise.
* tests/test-vasnprintf-posix.c (test_function): Likewise.
* tests/test-vasprintf-posix.c (test_function): Likewise.
* doc/posix-functions/fprintf.texi: Mention Solaris 10 bug as worked
around by gnulib.
* doc/posix-functions/printf.texi: Likewise.
* doc/posix-functions/snprintf.texi: Likewise.
* doc/posix-functions/sprintf.texi: Likewise.
* doc/posix-functions/vfprintf.texi: Likewise.
* doc/posix-functions/vprintf.texi: Likewise.
* doc/posix-functions/vsnprintf.texi: Likewise.
* doc/posix-functions/vsprintf.texi: Likewise.
* doc/posix-functions/dprintf.texi: Undo last commit.
* doc/posix-functions/vdprintf.texi: Likewise.
--- doc/posix-functions/dprintf.texi.orig Fri Dec 24 09:56:06 2010
+++ doc/posix-functions/dprintf.texiFri Dec 24 09:41:40 2010
@@ -24,9 +24,4 @@
Portability problems not fixed by Gnulib:
@itemize
-...@item
-This function mishandles large floating point precisions
-(for example, formatting 1.0 with @samp{%.511f})
-on some platforms:
-Solaris 10.
@end itemize
--- doc/posix-functions/fprintf.texi.orig Fri Dec 24 09:56:06 2010
+++ doc/posix-functions/fprintf.texiFri Dec 24 09:38:24 2010
@@ -55,6 +55,11 @@
floating-point and pointer output on some platforms:
Solaris 10/x86, mingw, BeOS.
@item
+This function mishandles large floating point precisions
+(for example, formatting 1.0 with @samp{%.511f})
+on some platforms:
+Solaris 10.
+...@item
This function can crash in out-of-memory conditions on some platforms:
MacOS X 10.3, FreeBSD 6.0, NetBSD 5.0.
@end itemize
@@ -69,9 +74,4 @@
Portability problems not fixed by Gnulib:
@itemize
-...@item
-This function mishandles large floating point precisions
-(for example, formatting 1.0 with @samp{%.511f})
-on some platforms:
-Solaris 10.
@end itemize
--- doc/posix-functions/printf.texi.origFri Dec 24 09:56:06 2010
+++ doc/posix-functions/printf.texi Fri Dec 24 09:39:25 2010
@@ -55,6 +55,11 @@
floating-point and pointer output on some platforms:
Solaris 10/x86, mingw, BeOS.
@item
+This function mishandles large floating point precisions
+(for example, formatting 1.0 with @samp{%.511f})
+on some platforms:
+Solaris 10.
+...@item
This function can crash in out-of-memory conditions on some platforms:
MacOS X 10.3, FreeBSD 6.0, NetBSD 5.0.
@end itemize
@@ -69,9 +74,4 @@
Portability problems not fixed by Gnulib:
@itemize
-...@item
-This function mishandles large floating point precisions
-(for example, formatting 1.0 with @samp{%.511f})
-on some platforms:
-Solaris 10.
@end itemize
--- doc/posix-functions/snprintf.texi.orig Fri Dec 24 09:56:06 2010
+++ doc/posix-functions/snprintf.texi Fri Dec 24 09:39:43 2010
@@ -69,6 +69,11 @@
floating-point and pointer output on some platforms:
Solaris 10/x86, mingw, BeOS.
@item
+This function mishandles large floating point precisions
+(for example, formatting 1.0 with @samp{%.511f})
+on some platforms:
+Solaris 10.
+...@item
This function can crash in out-of-memory conditions on some platforms:
MacOS X 10.3, FreeBSD 6.0, NetBSD 5.0.
@item
@@ -89,9 +94,4 @@
Portability problems not fixed by Gnulib:
@itemize
-...@item
-This function mishandles large floating point precisions
-(for example, formatting 1.0 with @samp{%.511f})
-on some platforms:
-Solaris 10.
@end itemize
RE: alphasort on HP-NonStop
Hi Bruno Hmmm, as per config.log and config.h configure apparently found alphasort and #defined _HAVE_ALPHASORT, I wonder why? configure:24953: checking for alphasort configure:24953: cc -o conftest -g -I/usr/local/include conftest.c 5 return 0; ^ /usr/local/Floss/gnulib/testdir-posix/conftest.c, line 302: warning(203): statement is unreachable configure:24953: $? = 0 configure:24953: result: yes Looks like a severe problem with my /usr/local/bin/cc wrapper script, using /usr/bin/c89 directly makes the linking fail, as it should. Ah! Found it in a lib called zutildll! And that indeed gets linked by my wrapper script. It is not documented anywhere, so I'm not sure whether it serves the purpose POSIX defined for this... Not sure whether I'd need to do an #undef HAVE_ALPHASORT or just add it's prototype and where to do any of this. I need to have a deeper look later, probably after X-mas. Bye, Jojo PS: Merry Christmas and a Happy New Year to all of you! -Original Message- From: Joachim Schmitz [mailto:j...@schmitz-digital.de] Sent: Thursday, December 23, 2010 2:40 PM To: 'Bruno Haible' Cc: 'bug-gnulib@gnu.org' Subject: RE: alphasort on HP-NonStop You mean add alphasort to gllib/dirent.in.h? We don't have an alphasort elsewhere And yes, we're quite a bit behind the current POSIX... -Original Message- From: Bruno Haible [mailto:br...@clisp.org] Sent: Thursday, December 23, 2010 1:40 PM To: Joachim Schmitz Cc: bug-gnulib@gnu.org Subject: Re: alphasort on HP-NonStop Joachim Schmitz wrote: alphasort missing, need to modify gllib/dirent.in.h? How? source='test-dirent-c++.cc' object='test-dirent-c++.o' libtool=no DEPDIR=.depsdepmode=none /bin/sh ./../build-aux/depcomp c++ -HAVE_CONFIG_H -I. -DGNULIB_STRICT_CHECKING=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib -I/usr/local/include -Wnowarn -c -o test-dirent-c++.o test-dirent-c++.cc _GL_CXXALIAS_SYS_CAST (alphasort, int, ^ /usr/local/Floss/gnulib/testdir-posix/gltests/./../gllib/dirent.h, line 471: error(363): the global scope has no alphasort Gnulib has an 'alphasort' module that provides a replacement when the function is missing. The error message here makes me think that the function exists on your system but its declaration is missing. Can you add the declaration to dirent.h? References: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/dirent.h.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/alphasort.html Bruno
Re: porting alignof to HP-NonStop
Joachim Schmitz wrote:
typedef struct { char slot1; char slot2; } char_helper;
((size_t)__INTADDR__struct { char __slot1; char __slot2; }
*)0)-__slot2)))
Is not equal to
((size_t)__INTADDR__char_helper *)0)-slot2)))
do you see why, resp. what's wrong here?
No, I don't see why. That's why I suggested that you reduce this test case
until you see why.
Bruno
Re: alphasort on HP-NonStop
Joachim Schmitz wrote: Ah! Found it in a lib called zutildll! And that indeed gets linked by my wrapper script. It is not documented anywhere, so I'm not sure whether it serves the purpose POSIX defined for this... Yes, when a function is not documented, it's most reliable to not use it. Not sure whether I'd need to do an #undef HAVE_ALPHASORT or just add it's prototype and where to do any of this. Or set the variable ac_cv_func_alphasort to no in your environment or in a local config.site file before running configure. Bruno
Re: printf.o HP-NonStop
Joachim Schmitz wrote: gllig/printf.o is not, but does not contain rpl_printf: $ nm -Pe gllib/printf.o E __stdio_fp F printf E rpl_vfprintf gllib/printf.o should define rpl_printf, not printf. Is some header file on your platform doing a #undef printf ? Bruno
Re: HOST_NAME_MAX on HP-NonStop
Joachim Schmitz wrote: Good question. In config.h I can only see: #define HOST_NAME_MAX So it gets #define'd but with no value ... Possibly because it does not #include arpa/nameser.h arpa/nameser.h is such a rarely included header file that we can ignore it here, and simply use a fallback of 256 (which is the maximum value of MAXHOSTNAMELEN on any platform). I'm applying this: 2010-12-24 Bruno Haible br...@clisp.org gethostname: Provide a fallback for HOST_NAME_MAX. * m4/gethostname.m4 (gl_FUNC_GETHOSTNAME): When neither HOST_NAME_MAX nor MAXHOSTNAMELEN is found in the usual system headers, use 256 instead. Reported by Joachim Schmitz j...@schmitz-digital.de. --- m4/gethostname.m4.orig Fri Dec 24 13:51:48 2010 +++ m4/gethostname.m4 Fri Dec 24 13:50:52 2010 @@ -1,5 +1,5 @@ -# gethostname.m4 serial 9 -dnl Copyright (C) 2002, 2008, 2009, 2010 Free Software Foundation, Inc. +# gethostname.m4 serial 10 +dnl Copyright (C) 2002, 2008-2010 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. @@ -83,7 +83,11 @@ #if HAVE_NETDB_H # include netdb.h #endif -]) +], + [dnl The system does not define MAXHOSTNAMELEN in any of the common + dnl headers. Use a safe fallback. + gl_cv_decl_HOST_NAME_MAX=256 + ]) fi fi ])
RE: alphasort on HP-NonStop
Thanks. I'll report this as a bug to HP NonStop development. Last change on the lib was that scandir() and scandir64() had been added, looks like alphasort() got added too, but not externalized. Bye, Jojo -Original Message- From: Bruno Haible [mailto:br...@clisp.org] Sent: Friday, December 24, 2010 12:25 PM To: Joachim Schmitz Cc: bug-gnulib@gnu.org Subject: Re: alphasort on HP-NonStop Joachim Schmitz wrote: Ah! Found it in a lib called zutildll! And that indeed gets linked by my wrapper script. It is not documented anywhere, so I'm not sure whether it serves the purpose POSIX defined for this... Yes, when a function is not documented, it's most reliable to not use it. Not sure whether I'd need to do an #undef HAVE_ALPHASORT or just add it's prototype and where to do any of this. Or set the variable ac_cv_func_alphasort to no in your environment or in a local config.site file before running configure. Bruno
sys_select: tweak
There is no reason to include sys/socket.h from sys/select.h except on native Windows platforms. I've tested this on various platforms. 2010-12-24 Bruno Haible br...@clisp.org sys_select: Remove unneeded include. * lib/sys_select.in.h: Don't include sys/socket.h on platforms that have sys/select.h. --- lib/sys_select.in.h.origFri Dec 24 16:21:19 2010 +++ lib/sys_select.in.h Fri Dec 24 16:19:49 2010 @@ -65,8 +65,11 @@ #ifndef _GL_SYS_SELECT_H #define _GL_SYS_SELECT_H -#if !...@have_sys_select_h@ || @REPLACE_SELECT@ +#if !...@have_sys_select_h@ /* A platform that lacks sys/select.h. */ +/* On native Windows platforms: + Get the 'fd_set' type. Also, gnulib's sys/socket.h redefines select + so as to hide the declaration from winsock2.h. */ # include sys/socket.h #endif
Re: sys/select.h HP-NonStop
Joachim Schmitz wrote:
Yes, but with a condition that apparently is not met (and to deeply
nested and complicated for me to grasp), hence my change:
diff -u ./gllib/sys_select.in.h.orig ./gllib/sys_select.in.h
--- ./gllib/sys_select.in.h.orig2010-10-10 16:05:05.0 -0500
+++ ./gllib/sys_select.in.h 2010-12-23 03:38:34.0 -0600
@@ -60,6 +60,8 @@
/* The include_next requires a split double-inclusion guard. */
# @INCLUDE_NEXT@ @NEXT_SYS_SELECT_H@
+#elif defined __TANDEM /* HP NonStop */
+# include sys/time.h
#endif
#ifndef _GL_SYS_SELECT_H
Symptoms were error reg. timeval, fd_set, FD_ISSET not being available
If that change worked for you, it means in particular that your platform
does not have sys/select.h. This should fix it:
2010-12-24 Bruno Haible br...@clisp.org
sys_select: Ensure all necessary types on NonStop Kernel.
* lib/sys_select.in.h: If the system does not have sys/select.h,
include sys/time.h.
* doc/posix-headers/sys_select.texi: Mention that it's missing on
NonStop Kernel.
Reported by Joachim Schmitz j...@schmitz-digital.de.
--- doc/posix-headers/sys_select.texi.orig Fri Dec 24 16:23:25 2010
+++ doc/posix-headers/sys_select.texi Fri Dec 24 16:22:49 2010
@@ -9,7 +9,7 @@
@itemize
@item
This header file is missing on some platforms:
-HP-UX 11.11, mingw, BeOS.
+HP-UX 11.11, NonStop Kernel, mingw, BeOS.
@item
This header file is not self-contained on some platforms: it requires
@code{sys/types.h} to be included first.
--- lib/sys_select.in.h.origFri Dec 24 16:23:25 2010
+++ lib/sys_select.in.h Fri Dec 24 16:23:04 2010
@@ -44,6 +44,8 @@
/* On OSF/1 4.0, sys/select.h provides only a forward declaration
of 'struct timeval', and no definition of this type.
+ Also, MacOS X, AIX, HP-UX, IRIX, Solaris, Interix declare select()
+ in sys/time.h.
But avoid namespace pollution on glibc systems. */
# ifndef __GLIBC__
# include sys/time.h
@@ -67,6 +69,9 @@
#if !...@have_sys_select_h@
/* A platform that lacks sys/select.h. */
+/* Get the 'struct timeval' and 'fd_set' types and the FD_* macros
+ on most platforms. */
+# include sys/time.h
/* On native Windows platforms:
Get the 'fd_set' type. Also, gnulib's sys/socket.h redefines select
so as to hide the declaration from winsock2.h. */
Re: gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX
On Wed, Nov 24, 2010 at 12:07:52PM -0800, Paul Eggert wrote: I pushed the following patch; could you please give it a try? From 531b8a416b6ae40f89808e1db8976eb25972e661 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Wed, 24 Nov 2010 12:05:43 -0800 Subject: [PATCH] stdint: port to GCC 4.3 + OSX + Octave + int, which would mess up C++ name mangling. */ + +#if INT64_MAX +# define GL_INT64_T -typedef unsigned long int gl_uint64_t; +#if UINT64_MAX # define GL_UINT64_T Any reason not to #ifdef INT64_MAX/UINT64_MAX instead of plain #if? With just #if we get preprocessor errors on hpux10.20 with hp cc: cc -DHAVE_CONFIG_H -I. -I.. -I./gllib -DASN1_BUILDING -Ae -z +O2 -c ASN1.c +Z -DPIC -o .libs/ASN1.o cpp: stdint.h, line 143: warning 2012: Unrepresentable preprocessor number 9223372036854775807ll. cpp: stdint.h, line 143: error 4038: Bad syntax for #if condition. cpp: stdint.h, line 166: warning 2012: Unrepresentable preprocessor number 18446744073709551615ull. cpp: stdint.h, line 166: error 4038: Bad syntax for #if condition. Peter -- Peter O'Gorman po...@thewrittenword.com
[PATCH] pipe: make obsoletion transition easier
* lib/pipe.h: Restore file as thin shim around spawn-pipe.h. * modules/pipe (Files): Include revived file. (Include): Drop reference, to mirror getdate's behavior. Signed-off-by: Eric Blake ebl...@redhat.com --- Since at this point we are not considering moving either all POSIX related modules or all application-level modules to a new naming convention, I think it's best to rename the application-level module 'pipe' at this point. Thanks for doing that, again. In a second step, in a couple of months, we'll be able to remove the module 'pipe' without much damage. I just update m4.git to the latest gnulib, and it failed to compile because it was expecting the old pipe.h. This patch mirrors what is done by the getdate transition module, by keeping the old name around until such time as packages have swapped to the new module. Therefore, I don't think we're quite at the point of removing the pipe module, yet. In a third step, later again, you can then rename 'pipe-posix' to 'pipe'. But yes, these three steps do sound appropriate. ChangeLog|7 +++ lib/pipe.h |2 ++ modules/pipe |2 +- 3 files changed, 10 insertions(+), 1 deletions(-) create mode 100644 lib/pipe.h diff --git a/ChangeLog b/ChangeLog index 9947f1f..28d6819 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-12-24 Eric Blake ebl...@redhat.com + + pipe: make obsoletion transition easier + * lib/pipe.h: Restore file as thin shim around spawn-pipe.h. + * modules/pipe (Files): Include revived file. + (Include): Drop reference, to mirror getdate's behavior. + 2010-12-24 Bruno Haible br...@clisp.org sys_socket: Hide mismatch of declarations on NonStop Kernel. diff --git a/lib/pipe.h b/lib/pipe.h new file mode 100644 index 000..3c1b4b8 --- /dev/null +++ b/lib/pipe.h @@ -0,0 +1,2 @@ +/* Obsolete; consider using spawn-pipe.h instead. */ +#include spawn-pipe.h diff --git a/modules/pipe b/modules/pipe index 3d6ccee..06e0706 100644 --- a/modules/pipe +++ b/modules/pipe @@ -8,6 +8,7 @@ Notice: This module is obsolete. Use the module 'spawn-pipe' instead. Files: +lib/pipe.h Depends-on: spawn-pipe @@ -17,7 +18,6 @@ configure.ac: Makefile.am: Include: -spawn-pipe.h License: GPL -- 1.7.3.4
[PATCH] stdint: avoid HP-UX 10.20 preprocessor bug
* lib/stdint.in.h (INT64_MAX, UINT64_MAX): Check via #ifdef rather
than #if.
* tests/test-floor2.c (main): Likewise.
Reported by Peter O'Gorman.
Signed-off-by: Eric Blake ebl...@redhat.com
---
+#if UINT64_MAX
# define GL_UINT64_T
Any reason not to #ifdef INT64_MAX/UINT64_MAX instead of plain #if? With
just #if we get preprocessor errors on hpux10.20 with hp cc:
Thanks for the report. When both forms work, #if is shorter than
#ifdef, and proves that the argument is either undefined or numeric,
which is why we prefer it. But since you have a proven case of a
preprocessor bug where the workaround is easy enough to implement, we
might as well go with the workaround and document why we did so.
cpp: stdint.h, line 143: warning 2012: Unrepresentable preprocessor
number 9223372036854775807ll.
I'm pushing this.
ChangeLog |6 ++
lib/stdint.in.h |7 ---
tests/test-floor2.c |2 +-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 28d6819..b0ddade 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2010-12-24 Eric Blake ebl...@redhat.com
+ stdint: avoid HP-UX 10.20 preprocessor bug
+ * lib/stdint.in.h (INT64_MAX, UINT64_MAX): Check via #ifdef rather
+ than #if.
+ * tests/test-floor2.c (main): Likewise.
+ Reported by Peter O'Gorman.
+
pipe: make obsoletion transition easier
* lib/pipe.h: Restore file as thin shim around spawn-pipe.h.
* modules/pipe (Files): Include revived file.
diff --git a/lib/stdint.in.h b/lib/stdint.in.h
index 70822b8..7270ad0 100644
--- a/lib/stdint.in.h
+++ b/lib/stdint.in.h
@@ -137,9 +137,10 @@ typedef unsigned int gl_uint32_t;
/* If the system defines INT64_MAX, assume int64_t works. That way,
if the underlying platform defines int64_t to be a 64-bit long long
int, the code below won't mistakenly define it to be a 64-bit long
- int, which would mess up C++ name mangling. */
+ int, which would mess up C++ name mangling. We must use #ifdef
+ rather than #if, to avoid an error with HP-UX 10.20 cc. */
-#if INT64_MAX
+#ifdef INT64_MAX
# define GL_INT64_T
#else
/* Do not undefine int64_t if gnulib is not being used with 64-bit
@@ -162,7 +163,7 @@ typedef long long int gl_int64_t;
# endif
#endif
-#if UINT64_MAX
+#ifdef UINT64_MAX
# define GL_UINT64_T
#else
# if ULONG_MAX 31 31 1 == 1
diff --git a/tests/test-floor2.c b/tests/test-floor2.c
index e239199..971f24a 100644
--- a/tests/test-floor2.c
+++ b/tests/test-floor2.c
@@ -144,7 +144,7 @@ check (double x)
int
main ()
{
-#if UINT64_MAX
+#ifdef UINT64_MAX
unsigned int highbits;
unsigned int lowbits;
int error = 0;
--
1.7.3.4
determining the program_invocation_name
Hi, How can some library code determine the name of the running program, for error message and display purposes, if the program's main() function has not stored argv[0] in a particular place? Let's be clear about two things: 1) This question is mostly irrelevant for libposix, because library functions in libposix should not call exit() and should not print error messages. The only ways out that a library function has is to call abort() if there was a programming error, and to return an error code or error message that the caller can then handle. 2) Even if we find an answer to this question, it does not magically resolve all problems with the 'error' module, because the question remains where the 'program_name' variable shall be allocated, and it is a portability problem for MacOS X, AIX, Solaris, Cygwin [1]. There was this thread [2] in 2006 where we found out that we needed some new API [3] because we did not want to implement the BSD functions with different semantics. Recently, Bastien Roucariès respawned the topic in two threads [4][5], by proposing to fetch the program invocation name (= argv[0] or a variant of it) through the API that 'ps' and 'top' typically use. Find attached a collection of the platform dependent code snippets. I added code for Cygwin, mingw (from progreloc.c), and OSF/1, and tested it on the various platforms. The results of this investigation are: 1) There are six different notions of program name. - get_program_invocation_short_name () This is what glibc calls 'program_invocation_short_name' and BSD calls 'getprogname ()'. It's the basename of the argv[0]. - get_program_invocation_short_name_truncated () This is like get_program_invocation_short_name (), except it is truncated to a certain number of bytes (14, 16, or 32). - get_program_invocation_name () This is what glibc calls 'program_invocation_name'. It's the argv[0] before the search in $PATH was performed. - get_program_absolute_name () This is like get_program_invocation_name(), except that it makes the result absolute by stuffing in the current directory if needed. - get_resolved_program_invocation_name () This is like get_program_invocation_name(), except that it resolves symbolic links and removes trivial filename components. - get_program_canonicalized_name () This is like a combination of get_program_absolute_name() and get_resolved_program_invocation_name(): It resolves symbolic links, removes trivial filename components, and stuffs in the current directory. 2) Each of the functions may fail, i.e. return NULL. 3) It's highly platform dependent. Here's the matrix of available functions: A = get_program_invocation_short_name () A x = get_program_invocation_short_name_truncated () B = get_program_invocation_name () C = get_program_absolute_name () D = get_resolved_program_invocation_name () E = get_program_canonicalized_name () | A | B | C | D | E | ---+---+---+---+---+---+ glibc/Linux | X | X | | | X | glibc/other | X | X | | | | uClibc/Linux | | | | | X | MacOS X | X | | X | | | FreeBSD | X | | | | | NetBSD| X | | | | | OpenBSD | X | | | | | AIX | x | X | | | | HP-UX | x | | | | | IRIX | x | | | | | OSF/1 | x | | | | | Solaris | X | | | X | | Cygwin| X | | | | X | mingw | | | | | X | Interix | | | | | | ---+---+---+---+---+---+ Given B, you can determine C, D, E, by assuming the current directory and $PATH have not changed since the program was launched. But given A only, one cannot determine B, C, D, E. And unfortunately, on many Unix platforms, A is the only thing you can get. What can we reasonably do with this? (a) We could create a new module that exports functions /* Returns the base name of argv[0], if known. */ const char *get_program_invocation_short_name (); /* Returns the truncated base name of argv[0], if known. */ const char *get_program_invocation_short_name_truncated (); size_t get_program_invocation_short_name_truncation_length (); /* Return argv[0], without resolving symlinks or current directory if possible. */ const char *get_program_invocation_name (); /* Return argv[0] as a canonical filename. Assumes that the current directory and $PATH have not changed since the program was launched. */ const char *get_program_canonicalized_name (); Of course these functions
Re: [PATCH] test-select: avoid warn_unused_result warnings
Hi Jim, You wrote on 2010-10-13 in http://lists.gnu.org/archive/html/bug-gnulib/2010-10/msg00318.html: * tests/test-select.c: Include macros.h. ASSERT that each call to read, write, and pipe succeeds. While not technically required, also check each close. The last part causes a failure on OSF/1 5.1: Unconnected socket test... passed Connected sockets test... test-select.c:357: assertion failed sh: 366989 Abort - core dumped FAIL: test-select The reason is that after one end of the connection has been closed, the close() on the other end fails, signalling that some bytes have been written have been lost. This patch avoids the failure. Since you said that it's not technically required to check each close(), I assume you agree. 2010-12-24 Bruno Haible br...@clisp.org select tests: Avoid failures on OSF/1 5.1. * tests/test-select.c (test_accept_first, test_socket_pair): Ignore failure of closing the last socket; it may fail with ECONNRESET. --- tests/test-select.c.origSat Dec 25 01:23:38 2010 +++ tests/test-select.c Sat Dec 25 01:22:32 2010 @@ -310,7 +310,7 @@ failed (cannot read data left in the socket by closed process); ASSERT (read (c, buf, 3) == 3); ASSERT (write (c, foo, 3) == 3); - ASSERT (close (c) == 0); + (void) close (c); /* may fail with errno = ECONNRESET */ } #endif } @@ -354,7 +354,7 @@ test_pair (c1, c2); ASSERT (close (c1) == 0); ASSERT (write (c2, foo, 3) == 3); - ASSERT (close (c2) == 0); + (void) close (c2); /* may fail with errno = ECONNRESET */ }
more select-tests updates
Hi Paolo,
While looking at tests/test-select.c for the OSF/1 failure, I found a couple
of small tweaks. Can you agree to these 4 patches?
1) The code for pipe() on Win32 is now in module 'pipe-posix'. And 'pipe-posix'
depends on 'unistd'.
2010-12-24 Bruno Haible br...@clisp.org
select tests: Use existing modules.
* modules/select-tests (Depends-on): Add pipe-posix, unistd.
(configure.ac): Don't test for unistd.h.
* tests/test-select.c: Include unistd.h always. Use pipe() as
declared in unistd.h.
--- modules/select-tests.orig Sat Dec 25 01:33:20 2010
+++ modules/select-testsSat Dec 25 01:33:15 2010
@@ -11,11 +11,13 @@
stdbool
netinet_in
arpa_inet
+unistd
sys_ioctl
extensions
inet_pton
errno
perror
+pipe-posix
socket
bind
setsockopt
@@ -27,7 +29,7 @@
gettimeofday
configure.ac:
-AC_CHECK_HEADERS_ONCE([unistd.h sys/wait.h])
+AC_CHECK_HEADERS_ONCE([sys/wait.h])
Makefile.am:
TESTS += test-select test-select-in.sh test-select-out.sh
--- tests/test-select.c.origSat Dec 25 01:33:20 2010
+++ tests/test-select.c Sat Dec 25 01:32:02 2010
@@ -42,6 +42,7 @@
#include string.h
#include netinet/in.h
#include arpa/inet.h
+#include unistd.h
#include fcntl.h
#include stdlib.h
#include stdbool.h
@@ -56,25 +57,18 @@
# define WIN32_NATIVE
#endif
-#ifdef WIN32_NATIVE
-#include io.h
-#define pipe(x) _pipe(x, 256, O_BINARY)
-#endif
-#ifdef HAVE_UNISTD_H
-#include unistd.h
-#endif
#ifdef HAVE_SYS_WAIT_H
-#include sys/wait.h
+# include sys/wait.h
#endif
#ifndef SO_REUSEPORT
-#define SO_REUSEPORTSO_REUSEADDR
+# define SO_REUSEPORTSO_REUSEADDR
#endif
#define TEST_PORT 12345
2) The arguments passed to function connect_to_socket() are true and false.
So it's actually a 'bool' argument.
2010-12-24 Bruno Haible br...@clisp.org
select tests: Use 'bool' where appropriate.
* tests/test-select.c (connect_to_socket): Change argument type to
'bool'.
--- tests/test-select.c.origSat Dec 25 01:33:20 2010
+++ tests/test-select.c Sat Dec 25 01:32:02 2010
@@ -134,7 +126,7 @@
}
static int
-connect_to_socket (int blocking)
+connect_to_socket (bool blocking)
{
int s;
struct sockaddr_in ia;
3) Because at least some Linux versions return in the timeout parameter the
unslept time (see http://linux.die.net/man/2/select), it is good practice
to not reuse a 'struct timeval' from a previous select() call for the next
select() call. Even though in this case the unslept time is probably
always zero, better use the safe way of coding.
2010-12-24 Bruno Haible br...@clisp.org
select tests: Safer way of handling timeout.
* tests/test-select.c (do_select_nowait): Zero-initialize the timeout
at every invocation.
--- tests/test-select.c.origSat Dec 25 01:33:20 2010
+++ tests/test-select.c Sat Dec 25 01:32:02 2010
@@ -210,7 +212,9 @@
static int
do_select_nowait (int fd, int ev)
{
- static struct timeval tv0;
+ struct timeval tv0;
+ tv0.tv_sec = 0;
+ tv0.tv_usec = 0;
return do_select (fd, ev, tv0);
}
4) A couple of comments for do_select(), since this function is used in all
the tests. (The reader may not be familiar with poll().)
2010-12-24 Bruno Haible br...@clisp.org
select tests: Improve comments.
* tests/test-select.c (do_select): Add comments.
--- tests/test-select.c.origSat Dec 25 01:33:20 2010
+++ tests/test-select.c Sat Dec 25 01:32:02 2010
@@ -50,8 +51,6 @@
#include macros.h
-enum { SEL_IN = 1, SEL_OUT = 2, SEL_EXC = 4 };
-
#if (defined _WIN32 || defined __WIN32__) ! defined __CYGWIN__
# define WIN32_NATIVE
#endif
@@ -171,10 +163,20 @@
}
-/* A slightly more convenient interface to select(2). */
+/* A slightly more convenient interface to select(2).
+ Waits until a specific event occurs on a file descriptor FD.
+ EV is a bit mask of events to look for:
+ SEL_IN - input can be polled without blocking,
+ SEL_OUT - output can be provided without blocking,
+ SEL_EXC - an exception occurred,
+ A maximum wait time is specified by TIMEOUT.
+ *TIMEOUT = { 0, 0 } means to return immediately,
+ TIMEOUT = NULL means to wait indefinitely. */
+
+enum { SEL_IN = 1, SEL_OUT = 2, SEL_EXC = 4 };
static int
-do_select (int fd, int ev, struct timeval *tv)
+do_select (int fd, int ev, struct timeval *timeout)
{
fd_set rfds, wfds, xfds;
int r, rev;
@@ -188,7 +190,7 @@
FD_SET (fd, wfds);
if (ev SEL_EXC)
FD_SET (fd, xfds);
- r = select (fd + 1, rfds, wfds, xfds, tv);
+ r = select (fd + 1, rfds, wfds, xfds, timeout);
if (r 0)
return r;
@@ -221,7 +225,7 @@
}
-/* Test poll(2) for TTYs. */
+/* Test select(2) for TTYs. */
#ifdef INTERACTIVE
static void
@@ -242,7 +246,7 @@
#endif
-/* Test poll(2) for unconnected nonblocking sockets. */
+/* Test select(2) for unconnected nonblocking sockets. */
static void
test_connect_first (void)
@@ -271,7 +275,7 @@
}
-/* Test
Re: determining the program_invocation_name
On 12/24/2010 01:41 PM, Bruno Haible wrote: Decide that it is better to have no gnulib API at all than an API that has portability problems. Given the results of your (impressive) research, I'm tempted to go with this approach. A fallback position might be to implement only A (the short name), with a function that always returns a nonnull value, even if it's only (unknown program) or (pid 34223) or something like that.
