EINTR

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

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

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 i

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

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

getaddrinfo on MinGW

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

Re: EINTR

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)

Fortran95 binding for posix/gnulib

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

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 (

Re: Fortran95 binding for posix/gnulib

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

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

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 tha

Re: Fortran95 binding for posix/gnulib

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 > A

Re: Fortran95 binding for posix/gnulib

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, w

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

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

Re: Fortran95 binding for posix/gnulib

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 wa

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

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

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

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

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

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 dire

Re: [PATCH]: pselect: new module

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 's

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

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/vsnprin

Re: [PATCH]: pselect: new module

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, T