EINTR

[Bruno Haible]

Ralf Wildenhues wrote:
> In the first example using 'read', don't you have to take care of EINTR
> so that './mycat9 < file' doesn't drop forget half the file after being
> suspended and continued again?

Excellent point. I thought that in programs that don't install signal handlers,
EINTR was last seen in SunOS 4, 15 years ago. But no, it also occurs in
MacOS X! Test program:

==
#include 
#include 
#include 

int
main ()
{
  for (;;)
{
  char buf[4096];
  ssize_t count = read (0, buf, sizeof (buf));
  if (count == 0)
break;
  if (count < 0)
{
  perror ("read");
  break;
}
  fwrite (buf, 1, count, stdout);
}
  return 0;
}
==

Run it, type Hello, then Ctrl-Z and the job control command 'fg'.
Result on all systems except MacOS X:

$ ./a.out 
Hello
Hello
^Z
[1]+  Stopped ./a.out
$ fg
./a.out
World
World

Result on MacOS X:

$ ./a.out 
Hello
Hello
^Z
[1]+  Stopped ./a.out
$ fg
./a.out
read: Interrupted system call

I have updated the blog / tutorial lesson, and I'm adding this to the gnulib
documentation:


2011-07-03  Bruno Haible  

Comments about EINTR.
* lib/safe-read.h: Explain the purpose of this module.
* lib/safe-write.h: Likewise.
* doc/posix-functions/read.texi: Mention EINTR and the 'safe-read'
module.
* doc/posix-functions/write.texi: Mention EINTR and the 'safe-write'
module.
Reported by Ralf Wildenhues .

--- doc/posix-functions/read.texi.orig  Sun Jul  3 13:33:13 2011
+++ doc/posix-functions/read.texi   Sun Jul  3 12:29:44 2011
@@ -17,4 +17,11 @@
 
 Portability problems not fixed by Gnulib:
 @itemize
+@item
+This function may fail with error @code{EINTR}, even in programs that don't
+install any signal handlers, on some platforms:
+MacOS X 10.5.
 @end itemize
+
+For handling @code{EINTR}, Gnulib provides a module @samp{safe-read} with a
+function @code{safe_read}.
--- doc/posix-functions/write.texi.orig Sun Jul  3 13:33:13 2011
+++ doc/posix-functions/write.texi  Sun Jul  3 12:29:40 2011
@@ -32,4 +32,11 @@
 
 Portability problems not fixed by Gnulib:
 @itemize
+@item
+This function may fail with error @code{EINTR}, even in programs that don't
+install any signal handlers, on some platforms:
+MacOS X 10.5.
 @end itemize
+
+For handling @code{EINTR}, Gnulib provides a module @samp{safe-write} with a
+function @code{safe_write}.
--- lib/safe-read.h.origSun Jul  3 13:33:13 2011
+++ lib/safe-read.h Sun Jul  3 12:57:35 2011
@@ -14,6 +14,19 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see .  */
 
+/* Some system calls may be interrupted and fail with errno = EINTR in the
+   following situations:
+ - The process is stopped and restarted (signal SIGSTOP and SIGCONT, user
+   types Ctrl-Z) on some platforms: MacOS X.
+ - The process receives a signal for which a signal handler was installed
+   with sigaction() with an sa_flags field that does not contain
+   SA_RESTART.
+ - The process receives a signal for which a signal handler was installed
+   with signal() and for which no call to siginterrupt(sig,0) was done,
+   on some platforms: AIX, HP-UX, IRIX, OSF/1, Solaris.
+
+   This module provides a wrapper around read() that handles EINTR.  */
+
 #include 
 
 #ifdef __cplusplus
--- lib/safe-write.h.orig   Sun Jul  3 13:33:13 2011
+++ lib/safe-write.hSun Jul  3 12:57:36 2011
@@ -14,6 +14,19 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see .  */
 
+/* Some system calls may be interrupted and fail with errno = EINTR in the
+   following situations:
+ - The process is stopped and restarted (signal SIGSTOP and SIGCONT, user
+   types Ctrl-Z) on some platforms: MacOS X.
+ - The process receives a signal for which a signal handler was installed
+   with sigaction() with an sa_flags field that does not contain
+   SA_RESTART.
+ - The process receives a signal for which a signal handler was installed
+   with signal() and for which no call to siginterrupt(sig,0) was done,
+   on some platforms: AIX, HP-UX, IRIX, OSF/1, Solaris.
+
+   This module provides a wrapper around write() that handles EINTR.  */
+
 #include 
 
 #define SAFE_WRITE_ERROR ((size_t) -1)

-- 
In memoriam Yuri Shchekochikhin 

Re: good place for blogging on C/POSIX programming?

[Bruno Haible]

Hi Karl, Paul,

Thank you for your feedback.

> I agree with Paul that having it just in a blog entry seems insufficiently
> advertised :).

Yes, in fact the text I wrote will also be valid and applicable in 5 or 10
years, therefore it's better put into a manual than into a blog.

> 3. Since this isn't gnulib specific, I'm not sure about having it in the
> gnulib manual.  But maybe it could be a new section about programming
> in general, especially if you have other topics in mind.

There are currently 3 pieces of documentation that deal with C programming:
  - The glibc manual,
  - The Autoconf manual's section "Portable C and C++ Programming",
  - The gnulib manual.

For my feeling, the section in the Autoconf manual does not really belong
there. Either we should have a separate manual about "Portable C and C++
Programming", or it should be moved to the gnulib manual.

Until this separate manual exists, I think the best place is the gnulib
manual.

> 4. I also agree with Paul about posting a news entry in gnulib with a
> url to wherever it ends up (your site or the manual or wherever).

Yes, I'll do this, then.

> In general, making more use of gnulib's news area (e.g., incompatible
> changes, major additions, other milestones) seems like it would be a
> good thing.

OK. I've enabled the news section on Savannah. News postings can be created
by any member of the Gnulib group on Savannah, but are not posted until
approved by either Jim or Eric or me.

I also sent a news entry about recent new features. Let's see whether it
appears on planet.gnu.org.

Bruno
-- 
In memoriam Yuri Shchekochikhin 

Re: good place for blogging on C/POSIX programming?

[Bruce Korb]

On 07/03/11 06:31, Bruno Haible wrote:

For my feeling, the section in the Autoconf manual does not really belong
there. Either we should have a separate manual about "Portable C and C++
Programming", or it should be moved to the gnulib manual.


That really sounds like the best solution to me:  a completely separate
manual -- that includes references to the "safe(r)" modules that jump
through all the hoops correctly.

getaddrinfo on MinGW

[Ludovic Courtès]

Hello,

The ‘getaddrinfo’ module doesn’t seem to work as advertised ;-) when
cross-building for MinGW.

>From , a file that includes
Gnulib’s  fails to build like this:

--8<---cut here---start->8---
/bin/sh ../libtool  --tag=CC   --mode=compile i686-pc-mingw32-gcc 
-DHAVE_CONFIG_H   -DBUILDING_LIBGUILE=1 -I../../guile-2.0.1.154-f3977 -I.. 
-I../../guile-2.0.1.154-f3977/lib -I../lib 
-I/nix/store/hwd5i31rikwdjmjhxn4d2xwlsxczsg0s-libffi-3.0.9-i686-pc-mingw32/lib/libffi-3.0.9/include
   
-I/nix/store/lqyvgsv21wmf15xnznwv5qi78p59zkfm-libunistring-0.9.3-i686-pc-mingw32/include
 -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wswitch-enum 
-fvisibility=hidden 
-I/nix/store/lli7w1b3kc5nwdwgq9c9ikhdx141bba4-boehm-gc-7.2pre20110122-i686-pc-mingw32/include
   -g -O2 -c -o net_db.lo ../../guile-2.0.1.154-f3977/libguile/net_db.c
libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 
-I../../guile-2.0.1.154-f3977 -I.. -I../../guile-2.0.1.154-f3977/lib -I../lib 
-I/nix/store/hwd5i31rikwdjmjhxn4d2xwlsxczsg0s-libffi-3.0.9-i686-pc-mingw32/lib/libffi-3.0.9/include
 
-I/nix/store/lqyvgsv21wmf15xnznwv5qi78p59zkfm-libunistring-0.9.3-i686-pc-mingw32/include
 -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wswitch-enum 
-fvisibility=hidden 
-I/nix/store/lli7w1b3kc5nwdwgq9c9ikhdx141bba4-boehm-gc-7.2pre20110122-i686-pc-mingw32/include
 -g -O2 -c ../../guile-2.0.1.154-f3977/libguile/net_db.c -o net_db.o
../../guile-2.0.1.154-f3977/libguile/net_db.c:460:1: error: 'AI_ALL' undeclared 
here (not in a function)
../../guile-2.0.1.154-f3977/libguile/net_db.c:460:1: error: bit-field 
'_gl_verify_error_if_negative' width not an integer constant
../../guile-2.0.1.154-f3977/libguile/net_db.c:482:33: warning: 'struct 
addrinfo' declared inside parameter list
../../guile-2.0.1.154-f3977/libguile/net_db.c:482:33: warning: its scope is 
only this definition or declaration, which is probably not what you want
../../guile-2.0.1.154-f3977/libguile/net_db.c: In function 'scm_from_addrinfo':
../../guile-2.0.1.154-f3977/libguile/net_db.c:490:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:491:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:492:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:493:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:494:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:494:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:496:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:496:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c: In function 'scm_getaddrinfo':
../../guile-2.0.1.154-f3977/libguile/net_db.c:614:19: error: storage size of 
'c_hints' isn't known
../../guile-2.0.1.154-f3977/libguile/net_db.c:657:3: warning: implicit 
declaration of function 'getaddrinfo'
../../guile-2.0.1.154-f3977/libguile/net_db.c:665:10: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:665:19: warning: left-hand 
operand of comma expression has no effect
../../guile-2.0.1.154-f3977/libguile/net_db.c:666:2: warning: passing argument 
1 of 'scm_from_addrinfo' from incompatible pointer type
../../guile-2.0.1.154-f3977/libguile/net_db.c:482:1: note: expected 'const 
struct addrinfo *' but argument is of type 'struct addrinfo *'
../../guile-2.0.1.154-f3977/libguile/net_db.c:668:7: warning: implicit 
declaration of function 'freeaddrinfo'
../../guile-2.0.1.154-f3977/libguile/net_db.c:614:19: warning: unused variable 
'c_hints'
../../guile-2.0.1.154-f3977/libguile/net_db.c: At top level:
../../guile-2.0.1.154-f3977/libguile/net_db.c:680:1: error: 'EAI_BADFLAGS' 
undeclared here (not in a function)
../../guile-2.0.1.154-f3977/libguile/net_db.c:680:1: error: bit-field 
'_gl_verify_error_if_negative' width not an integer constant
../../guile-2.0.1.154-f3977/libguile/net_db.c: In function 'scm_gai_strerror':
../../guile-2.0.1.154-f3977/libguile/net_db.c:744:3: warning: implicit 
declaration of function 'gai_strerror'
../../guile-2.0.1.154-f3977/libguile/net_db.c:744:3: warning: passing argument 
1 of 'scm_from_locale_string' makes pointer from integer without a cast
../../guile-2.0.1.154-f3977/libguile/strings.h:134:13: note: expected 'const 
char *' but argument is of type 'int'
--8<---cut here---end--->8---

Clearly the AI_ constants and ‘struct addrinfo’ aren’t defined by
.

The relevant part of the ‘configure’ output is [0]:

--8<---cut here---start->8---
checking whether getaddrinfo is declared without a macro... no
checking whether fr

Re: EINTR

[Bruno Haible]

Hi all,

I wrote:
> ... in programs that don't install signal handlers, EINTR ... also occurs in
> MacOS X!

It is worse than that:

1) Even on Linux, even when the signal handlers have the SA_RESTART flag set,
   some system call (like msgrcv(), but not read()) can fail with EINTR.
   See [1].

2) On all systems, when a signal handler has the SA_RESTART flag cleared,
   not only the read() system call will fail with EINTR, but also an fread()
   call will fail and set the stream's error bit.

   POSIX specifies it like this: [2]

   Test case: [3]. Run it, type Hello then Ctrl-C. Result is:

   $ ./a.out
   Hello
   ^CSIGINT!
   fread: Interrupted system call
   Hello

   Tested on Linux, MacOS X, FreeBSD, OpenBSD, AIX, HP-UX, IRIX, OSF/1,
   Solaris, Cygwin.

3) On MacOS X, SIGSTOP and SIGCONT make not only read() fail with EINTR, but
   fread() as well.

   Test case: [3]. Run it, type Hello then Ctrl-Z then fg. Result is:

   $ ./a.out
   Hello
   ^Z
   [1]+  Stopped ./a.out
   $ fg
   ./a.out
   fread: Interrupted system call
   Hello

   $ ./a.out --unbuffered
   Hello
   Hello
   ^Z
   [1]+  Stopped ./a.out --unbuffered
   $ fg
   ./a.out --unbuffered
   fread: Interrupted system call

   This was also reported in [4].

   I would expect that EINTR also occurs in write() and fwrite() when writing
   to a pipe that is temporarily full, but I can't easily reproduce this.

I think we need safe_fread() and safe_fgetc() functions. What do you think?

Bruno


[1] 
http://us.generation-nt.com/sigstop-interrupted-system-call-help-183657841.html
[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/fread.html
[3]
=
#include 
#include 
#include 
#include 
#include 

static void handler (int sig) { write (1, "SIGINT!\n", 8); }

int
main (int argc, char *argv[])
{
  int unbuffered = (argc > 1 && strcmp (argv[1], "--unbuffered") == 0);
  signal (SIGINT, handler);
  siginterrupt (SIGINT, 1);
  for (;;)
{
  char buf[4096];
  size_t bufsize = (unbuffered ? 1 : sizeof (buf));
  size_t count;
  errno = 0;
  count = fread (buf, 1, bufsize, stdin);
  if (count < bufsize && errno != 0)
perror ("fread");
  if (count > 0)
fwrite (buf, 1, count, stdout);
  if (count < bufsize)
break;
}
  return 0;
}
=
[4] 
http://factor-language.blogspot.com/2010/09/two-things-every-unix-developer-should.html
-- 
In memoriam Yuri Shchekochikhin 

Fortran95 binding for posix/gnulib

[Bastien ROUCARIES]

Hi,

Do you think it is worthwhile to contribute module (in fortran95
sense) for binding posix to fortran.

I believe it is directly good to use gnulib instead then system posix
libc in order to improve portability.

Would you consider this for inclusion ?

bastien

Re: EINTR

[Bastien ROUCARIES]

On Sun, Jul 3, 2011 at 5:36 PM, Bruno Haible  wrote:
> Hi all,
>
> I wrote:
>> ... in programs that don't install signal handlers, EINTR ... also occurs in
>> MacOS X!
>
> It is worse than that:
>
> 1) Even on Linux, even when the signal handlers have the SA_RESTART flag set,
>   some system call (like msgrcv(), but not read()) can fail with EINTR.
>   See [1].

Report to vger al viro and alan cox have fixed problem like this
sometime ago. It is considered backported to stable

> 2) On all systems, when a signal handler has the SA_RESTART flag cleared,
>   not only the read() system call will fail with EINTR, but also an fread()
>   call will fail and set the stream's error bit.
>
>   POSIX specifies it like this: [2]
>
>   Test case: [3]. Run it, type Hello then Ctrl-C. Result is:
>
>   $ ./a.out
>   Hello
>   ^CSIGINT!
>   fread: Interrupted system call
>   Hello
>
>   Tested on Linux, MacOS X, FreeBSD, OpenBSD, AIX, HP-UX, IRIX, OSF/1,
>   Solaris, Cygwin.
>
> 3) On MacOS X, SIGSTOP and SIGCONT make not only read() fail with EINTR, but
>   fread() as well.
>
>   Test case: [3]. Run it, type Hello then Ctrl-Z then fg. Result is:
>
>   $ ./a.out
>   Hello
>   ^Z
>   [1]+  Stopped                 ./a.out
>   $ fg
>   ./a.out
>   fread: Interrupted system call
>   Hello
>
>   $ ./a.out --unbuffered
>   Hello
>   Hello
>   ^Z
>   [1]+  Stopped                 ./a.out --unbuffered
>   $ fg
>   ./a.out --unbuffered
>   fread: Interrupted system call
>
>   This was also reported in [4].
>
>   I would expect that EINTR also occurs in write() and fwrite() when writing
>   to a pipe that is temporarily full, but I can't easily reproduce this.
>
> I think we need safe_fread() and safe_fgetc() functions. What do you think?
>
> Bruno
>
>
> [1] 
> http://us.generation-nt.com/sigstop-interrupted-system-call-help-183657841.html
> [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/fread.html
> [3]
> =
> #include 
> #include 
> #include 
> #include 
> #include 
>
> static void handler (int sig) { write (1, "SIGINT!\n", 8); }
>
> int
> main (int argc, char *argv[])
> {
>  int unbuffered = (argc > 1 && strcmp (argv[1], "--unbuffered") == 0);
>  signal (SIGINT, handler);
>  siginterrupt (SIGINT, 1);
>  for (;;)
>    {
>      char buf[4096];
>      size_t bufsize = (unbuffered ? 1 : sizeof (buf));
>      size_t count;
>      errno = 0;
>      count = fread (buf, 1, bufsize, stdin);
>      if (count < bufsize && errno != 0)
>        perror ("fread");
>      if (count > 0)
>        fwrite (buf, 1, count, stdout);
>      if (count < bufsize)
>        break;
>    }
>  return 0;
> }
> =
> [4] 
> http://factor-language.blogspot.com/2010/09/two-things-every-unix-developer-should.html
> --
> In memoriam Yuri Shchekochikhin 
> 
>
>

Re: Fortran95 binding for posix/gnulib

[Bruno Haible]

Hi Bastien,

> ... binding posix to fortran.

Yes apparently it requires explicit binding code, cf. [1][2]

> Would you consider this for inclusion ?

Yes, why not? Fortran is sufficiently well supported by GCC and by Automake.
Just make sure that your modules follow the gnulib conventions for the module
descriptions - and here I'd say, put all the module descriptions into a
subdirectory modules/fortran/ -, and that you follow the GNU conventions for
Fortran code (whatever these may be - you can find out by looking at octave
in octave-3.4.2/libcruft/ [3]).

Bruno

[1] http://www.nongnu.org/posix90/
[2] https://savannah.nongnu.org/projects/posix90
[3] http://hg.savannah.gnu.org/hgweb/octave/file/944cf42c699e/libcruft
-- 
In memoriam Yuri Shchekochikhin 

Re: uuencode: multi-bytes char in remote file name contains bytes >0x80

[Bruce Korb]

On 07/03/11 04:14, 張叁 wrote:

my code is just showing my meaning.
may not works well.


Hi Duhuanpeng,

RE: enhancement to have uuencode encode output file name:

A few other things that will be needed:

1.  changes to mark the file name as an encoded file name
2.  parallel changes to uudecode that will then convert the
hex encoding of the file name to the file name to actually use
3.  This should be an option to uuencode, rather than a compile time setting.
uudecode should detect it.
4.  research into uuencode/uudecode to ensure the format enhancement
is compatible with the POSIX spec (does nothing to violate it):
http://pubs.opengroup.org/onlinepubs/009604599/utilities/uuencode.html
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uudecode.html

My reading of it seems to indicate that there isn't any wiggle room on the
"begin" line, for either base 64 or traditional encoding.  I think it would
require a preamble line that put uudecode into a non-POSIX state wherein
uudecode would know that the input file name was encoded.

Given that the encoded file may get handed off to a uudecode that
knows nothing about this magical state, the file name encoding should
encode '/' characters with the '/' character.  The technique in your
patch simply hex encodes the entire file name string.

I've CC-ed the gnulib list because there are folks there much more i18n
literate there than I am.

Sorry to make it so difficult

Regards, Bruce

Re: Fortran95 binding for posix/gnulib

[Bastien ROUCARIES]

Le dimanche 3 juillet 2011 19:32:42, Bruno Haible a écrit :
> Hi Bastien,
> 
> > ... binding posix to fortran.
> 
> Yes apparently it requires explicit binding code, cf. [1][2]
> 
> > Would you consider this for inclusion ?
> 
> Yes, why not? Fortran is sufficiently well supported by GCC and by
> Automake. Just make sure that your modules follow the gnulib conventions
> for the module descriptions - and here I'd say, put all the module
> descriptions into a subdirectory modules/fortran/ -, and that you follow
> the GNU conventions for Fortran code (whatever these may be - you can find
> out by looking at octave in octave-3.4.2/libcruft/ [3]).

Ok thank you

Fist piece of work will be to creat a gnulib module per posix header. I will 
begin by errno.

How could I get a list of pair name/value of every errno supported on the 
plateform ? i will prefer a solution that work with a 
cross compiler. I am thinking about using cpp then sed but is ugly as hell...

Bastien

> Bruno
> 
> [1] http://www.nongnu.org/posix90/
> [2] https://savannah.nongnu.org/projects/posix90
> [3] http://hg.savannah.gnu.org/hgweb/octave/file/944cf42c699e/libcruft

Re: Fortran95 binding for posix/gnulib

[Bruno Haible]

Bastien ROUCARIES wrote:
> Fist piece of work will be to creat a gnulib module per posix header. I will 
> begin by errno.
> 
> How could I get a list of pair name/value of every errno supported on the 
> plateform ?

This was discussed in the thread starting at [1].

But if it is so complicated, why not start with a simpler task, that is,
with another, smaller header file?

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00042.html
-- 
In memoriam Yuri Shchekochikhin 

Re: uuencode: multi-bytes char in remote file name contains bytes >0x80

[Bruno Haible]

Referring to
:

An obvious problem with the patch is that it considers a file name to be a
byte sequence. But different users may work in different locales, with
different encodings. If a Chinese user with file names in GB18030 encoding
sends a file to a user whose file names are UTF-8 encoded, or vice versa, the
file name needs to be converted. The usual approach for such cases is to use
UTF-8 as a "pivot" encoding. For example, in 'pax' [1] file names are
transferred in UTF-8 encoding.

But actually, what's the point of the patch? The most frequently used
archive programs for interchange are probably 'tar'/'pax', 'zip', and '7-zip'.
- 'pax' has support for Unicode file names [1]; the biggest problem is that
  the 'pax' format is the default one for GNU 'tar'.
- 'zip' has support for Unicode file names [2][3].
- '7-zip' supports Unicode file names as well [4].

Users who really want to transfer files with non-ASCII names can use one
of these three archive formats and send an uuencoded archive.

Bruno

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
[2] http://www.info-zip.org/UnZip.html
[3] 
http://info.michael-simons.eu/2010/01/05/create-zip-archives-containing-unicode-filenames-with-java/
[4] http://www.7-zip.org/7z.html
-- 
In memoriam Yuri Shchekochikhin 

Re: Fortran95 binding for posix/gnulib

[Bastien ROUCARIES]

Le dimanche 3 juillet 2011 22:20:07, Bruno Haible a écrit :
> Bastien ROUCARIES wrote:
> > Fist piece of work will be to creat a gnulib module per posix header. I
> > will begin by errno.
> > 
> > How could I get a list of pair name/value of every errno supported on the
> > plateform ?
> 
> This was discussed in the thread starting at [1].
> 
> But if it is so complicated, why not start with a simpler task, that is,
> with another, smaller header file?

In case of error I need to test error. So I was begin by this header.
Newt one is unistd

> Bruno
> 
> [1] http://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00042.html

Re: good place for blogging on C/POSIX programming?

[Karl Berry]

in fact the text I wrote will also be valid and applicable in 5 or 10
years

We can hope.

Until this separate manual exists, I think the best place is the
gnulib manual.

Indeed, I think the gnulib manual is the best place, especially if
gnulib modules are going to be discussed.  I don't see much gain in
introducing the overhead of another manual.

[PATCH] maint.mk: correct omissions in prohibit_argmatch_without_use check

[Jim Meyering]

FYI,

>From 84fb438212273a62452a0eea47dc695e0c3c911f Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Sun, 3 Jul 2011 23:00:15 +0200
Subject: [PATCH] maint.mk: correct omissions in prohibit_argmatch_without_use
 check

This rule would mistakenly report that argmatch.h is included without
use even when both the argmatch and invalid_arg macro were used.
* top/maint.mk (sc_prohibit_argmatch_without_use): Also detect uses
of argmatch and invalid_arg.
---
 ChangeLog|8 
 top/maint.mk |2 +-
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 79b10be..4939b80 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-07-03  Jim Meyering  
+
+   maint.mk: correct omissions in prohibit_argmatch_without_use check
+   This rule would mistakenly report that argmatch.h is included without
+   use even when both the argmatch and invalid_arg macro were used.
+   * top/maint.mk (sc_prohibit_argmatch_without_use): Also detect uses
+   of argmatch and invalid_arg.
+
 2011-07-03  Bruno Haible  

Comments about EINTR.
diff --git a/top/maint.mk b/top/maint.mk
index e6e03a8..725e52d 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -516,7 +516,7 @@ sc_prohibit_safe_read_without_use:

 sc_prohibit_argmatch_without_use:
@h='argmatch.h' \
-   
re='(\<(ARRAY_CARDINALITY|X?ARGMATCH(|_TO_ARGUMENT|_VERIFY))\>|\

Re: would like to break sys_select's dependency on sys_socket

[Bruno Haible]

Hi Paul,

> Here's what I just now pushed.  It works for non-Windows... but has not been 
> tested
> on native Windows.

And it does not work on native Windows. Here's a build of
  ./gnulib-tool --create-testdir --dir=... --with-tests --single-configure 
sys_select
on mingw:

make[4]: Entering directory 
`/home/bruno/multibuild-1132/mingw2009/testdir1/gltests'
gcc-3 -mno-cygwin -DHAVE_CONFIG_H -I. -I..  -DGNULIB_STRICT_CHECKING=1 
-DIN_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib 
-I/usr/local/mingw/include -Wall  -g -O2 -MT test-sys_select.o -MD -MP -MF 
.deps/test-sys_select.Tpo -c -o test-sys_select.o test-sys_select.c
In file included from test-sys_select.c:21:
../gllib/sys/select.h:85:26: sys/socket.h: No such file or directory
test-sys_select.c: In function `main':
test-sys_select.c:31: error: `fd_set' undeclared (first use in this function)
test-sys_select.c:31: error: (Each undeclared identifier is reported only once
test-sys_select.c:31: error: for each function it appears in.)
test-sys_select.c:31: error: parse error before "fds"
test-sys_select.c:32: warning: implicit declaration of function `FD_ZERO'
test-sys_select.c:32: error: `fds' undeclared (first use in this function)
make[4]: *** [test-sys_select.o] Error 1

On native Windows,
  -  does not exist natively; gnulib provides it.
  - The type fd_set and the FD_ZERO etc. macros are defined in .
Before your patch they were included via #include  which did
#include ; now they are missing.
  - The gnulib macro that defines HAVE_WINSOCK2_H is gl_HEADER_SYS_SOCKET or,
at least, gl_PREREQ_SYS_H_WINSOCK2. Such an invocation is fortunately still
present in m4/sys_select_h.m4.

> This is so that Emacs doesn't have to drag in m4/sockpfaf.m4

Actually nothing in module 'sys_socket' requires m4/sockpfaf.m4. Only the
modules 'inet_ntop', 'inet_pton', 'getaddrinfo' need it. But let's do this
simplification after you've fixed the 'sys_select' module. One thing after
the other.

Bruno
-- 
In memoriam Yuri Shchekochikhin 

Re: [PATCH]: pselect: new module

[Bruno Haible]

Hi Paul,

> +/* Get definition of 'sigset_t'.
> +   But avoid namespace pollution on glibc systems.  */
> +#if !(defined __GLIBC__ && !defined __UCLIBC__)
> +# include 
> +#endif

According to doc/posix-headers/signal.texi, it is not enough to
include . You also need add a module dependency from
'sys_select' to 'signal'.

Also, it would be useful to enhance tests/test-sys_select.c to verify
that sigset_t is indeed defined (since POSIX requests this type to be
defined in ).

> +#if @GNULIB_PSELECT@
> +# if @REPLACE_PSELECT@
> +#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
> +#   undef pselect
> +#   define pselect rpl_pselect
> +#  endif
> +_GL_FUNCDECL_RPL (pselect, int,
> +  (int, fd_set *restrict, fd_set *restrict, fd_set *restrict,
> +   struct timespec const *restrict, const sigset_t 
> *restrict));
> +_GL_CXXALIAS_RPL (pselect, int,
> +  (int, fd_set *restrict, fd_set *restrict, fd_set *restrict,
> +   struct timespec const *restrict, const sigset_t 
> *restrict));
> +# else
> +#  if !@HAVE_PSELECT@
> +_GL_FUNCDECL_SYS (pselect, int,
> +  (int, fd_set *restrict, fd_set *restrict, fd_set *restrict,
> +   struct timespec const *restrict, const sigset_t 
> *restrict));
> +#  endif
> +_GL_CXXALIAS_SYS (pselect, int,
> +  (int, fd_set *restrict, fd_set *restrict, fd_set *restrict,
> +   struct timespec const *restrict, const sigset_t 
> *restrict));

Good. But here also, it would be useful to enhance the unit test
tests/test-sys_select-c++.cc to verify that the function is declared
correctly in C++ mode.

> +# if HAVE_RAW_DECL_PSELECT
> +_GL_WARN_ON_USE (pselect, "pselect is not portable - "
> + "use gnulib module pselect for portability");

For HAVE_RAW_DECL_PSELECT to be defined, you need to augment the list of
functions to check in m4/sys_select_h.m4 line 67 (the argument of
gl_WARN_ON_USE_PREPARE).

> +AC_CACHE_CHECK([whether signature of pselect conforms to POSIX],
> +  gl_cv_sig_pselect,
> +  [AC_LINK_IFELSE(
> +  [AC_LANG_PROGRAM(
> +   [[#include 
> + ]],
> +   [[int (*p) (int, fd_set *, fd_set *, fd_set *restrict,
> +   struct timespec const *restrict,
> +   sigset_t const *restrict) = pselect;
> + return !p;]])],

Tabs are unwelcome in gnulib source files, because they make the indentation
look incorrect.

> +  if (sigmask)
> +sigprocmask (SIG_SETMASK, sigmask, &origmask);

If the emulation uses sigprocmask, the module needs to depend on module
'sigprocmask'. See doc/posix-functions/sigprocmask.texi.

> +configure.ac:
> +gl_FUNC_PSELECT
> +if test $REPLACE_PSELECT = 1; then
> +  AC_LIBOBJ([pselect])
> +fi

The condition ought to be
test $HAVE_PSELECT = 0 || test $REPLACE_PSELECT = 1
like for many other functions (see e.g. modules/nanosleep).

> +Link:
> +

The replacement is based on the select() function, and the 'select' module
requires linking with $(LIBSOCKET). The 'pselect' module therefore needs to
mention the same link requirement.

> I've tested it on Solaris 8 (!) and Fedora 14 for starters.

How did you test it? I don't see any unit test. Without a unit test, you
cannot even guarantee that the function is defined on platforms which
lack it (which is probably why you didn't notice the missing
'test $HAVE_PSELECT = 0').

For the unit tests, I would copy and adapt tests/test-select*.

Last not least, the documentation: doc/posix-functions/pselect.texi has not
been modified.

Bruno
-- 
In memoriam Yuri Shchekochikhin 

Re: [PATCH] snprintf: guarantee %1$d, for libintl

[Bruno Haible]

Hi Eric,

> diff --git a/ChangeLog b/ChangeLog
> index fcc2e6e..5f3ffb7 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,13 @@
> +2011-07-01  Eric Blake  
> +
> + snprintf: guarantee %1$d, for libintl
> + * m4/snprintf.m4 (gl_FUNC_SNPRINTF): Require %1$d support.
> + * m4/vsnprintf.m4 (gl_FUNC_VSNPRINTF): Likewise.
> + * doc/posix-functions/snprintf.texi (snprintf): Update.
> + * doc/posix-functions/vsnprintf.texi (vsnprintf): Likewise.
> + * tests/test-snprintf.c (main): Enhance test.
> + * tests/test-vsnprintf.c (main): Likewise.

This patch is all right.

I knew it was risky to provide an snprintf replacement in libintl that fixes
the %n$ interpretation but not the return value, and on the other hand gnulib
also may or may not replace snprintf... Thanks for all the analysis.

The changes warrant some comments, but we can add them later. I'm too tired for
today.

Bruno
-- 
In memoriam Yuri Shchekochikhin 

Re: [PATCH]: pselect: new module

[Bruno Haible]

Hi Paul,

More comments:

> +++ b/m4/pselect.m4
> @@ -0,0 +1,31 @@
> +# pselect.m4

No serial number here?

> +  if test $ac_cv_func_pselect = no || test $gl_cv_sig_pselect = no; then
> +REPLACE_PSELECT=1
> +  fi

> +#undef pselect
> +

> +int
> +rpl_pselect (int nfds, fd_set *restrict rfds,

These are not the usual idioms, and will define a symbol 'rpl_pselect' when
'pselect' would be more appropriate (which is disturbing when debugging).

To follow the usual idioms:
  - set HAVE_PSELECT = 0, not REPLACE_PSELECT = 1, if the function doesn't 
exist,
  - define the function pselect, not rpl_pselect,
  - don't #undef pselect, since you aren't going to call it in this file.

Bruno
-- 
In memoriam Yuri Shchekochikhin