_GL_CXXALIAS_SYS (raise, int, (int sig)); in signal.h may give complie error in C++ source.

In the bug tracker octave, in which gnulib components are used, _GL_CXXALIAS_SYS (raise, int, (int sig)); in signal.h seems to give compile error. https://savannah.gnu.org/bugs/?34378 John W. Eaton said in comment #3 in the above tracker that * I'm fai

Re: fdopen on MSVC

On 09/26/2011 04:40 PM, Bruno Haible wrote: On glibc systems (and probably many others as well), the invalid file descriptor is already caught by fdopen(). But there is no guarantee that all systems do this. But this is gnulib. _We_ can make that guarantee for all systems, via the fdopen mod

Re: fdopen on MSVC

Hi Eric, > If fdopen(-1,"r") returns anything besides NULL in the first place, then > that is a bug in fdopen(). Nope. POSIX:2008 says in : "The fdopen() function MAY fail if: [EBADF] The fildes argument is

Re: fdopen on MSVC

On 09/26/2011 04:30 PM, Eric Blake wrote: If fdopen(-1,"r") returns anything besides NULL in the first place, then that is a bug in fdopen(). All right, POSIX states that EBADF is a may fail, rather than a shall fail, in that situation. But do we know of any implementations that actually ret

Re: fdopen on MSVC

On 09/26/2011 04:17 PM, Bruno Haible wrote: Paolo Bonzini asked: * modules/fclose-tests (Depends-on): Add fdopen. * modules/fflush-tests (Depends-on): Likewise. * modules/fgetc-tests (Depends-on): Likewise. * modules/fputc-tests (Depends-on): Likewise. * m

Re: getline vs linebuffer

On 09/26/2011 04:04 PM, Eric Blake wrote: On 09/26/2011 03:47 PM, Reuben Thomas wrote: Is linebuffer obsoleteable in the face of standardized getline and friends? Not necessarily, because linebuffer provides a slightly different interface that might be easier to use. However, I do argue that b

Re: getline vs linebuffer

On 26 September 2011 23:19, Eric Blake wrote: > But a patch for both modules that references the other may indeed be > worthwhile. Great, I'll write something (and I find your arguments convincing). At the moment the short descriptions in the module files are identical, which is confusing. The c

Re: getline vs linebuffer

On 09/26/2011 04:06 PM, Reuben Thomas wrote: On 26 September 2011 23:04, Eric Blake wrote: On 09/26/2011 03:47 PM, Reuben Thomas wrote: Is linebuffer obsoleteable in the face of standardized getline and friends? Not necessarily, because linebuffer provides a slightly different interface tha

Re: fdopen on MSVC

Paolo Bonzini asked: > > * modules/fclose-tests (Depends-on): Add fdopen. > > * modules/fflush-tests (Depends-on): Likewise. > > * modules/fgetc-tests (Depends-on): Likewise. > > * modules/fputc-tests (Depends-on): Likewise. > > * modules/fread-tests (Depends-on): Likewise. > >

Re: getline vs linebuffer

Hi Reuben, > Is linebuffer obsoleteable in the face of standardized getline and friends? I'm not the maintainer of either of these modules, but I don't consider 'linebuffer' to be obsolete. Whenever I have to understand the calling convention of getline(), I get dizzy. What will happen if linept

Re: getline vs linebuffer

On 26 September 2011 23:04, Eric Blake wrote: > On 09/26/2011 03:47 PM, Reuben Thomas wrote: >> >> Is linebuffer obsoleteable in the face of standardized getline and >> friends? > > Not necessarily, because linebuffer provides a slightly different interface > that might be easier to use. If other

Re: Licence for gnulib.mk slightly vague

On 09/26/11 10:40, Glenn Morris wrote: > There's no information about which version of the GPL. > m4/gl-comp.m4 seems to have the same issue. Thanks for mentioning this. Iif it bothers you it may bother someone else, and it's not that hard to clarify, so I changed it in gnulib with the patch enc

Re: getline vs linebuffer

On 09/26/2011 03:47 PM, Reuben Thomas wrote: Is linebuffer obsoleteable in the face of standardized getline and friends? Not necessarily, because linebuffer provides a slightly different interface that might be easier to use. However, I do argue that both linebuffer and getdelim can be writt

Re: Relocation patch for cygwin

[Dropping cygwin list from CC.] Charles Wilson wrote: > > in cygwin libintl is expected to place in /bin so there's no use > > of relocatable. > > Right, and it is intended that, in the cygwin official packages, both > libiconv and libintl are built without relocation support. If that > isn't tr

Re: Licence for gnulib.mk slightly vague

Simon Josefsson wrote: > > The copy of gnulib.mk in Emacs says: > > > > # This file is free software, distributed under the terms of the GNU > > # General Public License. As a special exception to the GNU General > > # Public License, this file may be distributed as part of a program >

getline vs linebuffer

Is linebuffer obsoleteable in the face of standardized getline and friends? -- http://rrt.sc3d.org

Re: Bug in base64, new module base32

On 09/26/2011 11:58 AM, Gijs van Tulder wrote: Hi Simon, Thanks for accepting the patch. Simon Josefsson writes: There seems to be some memory leaks in the self-tests, although maybe they are inherited from the base64 self-test? The memory leaks seem to be related to the tests. The exact sam

Re: Licence for gnulib.mk slightly vague

Glenn Morris writes: > Hi, > > The copy of gnulib.mk in Emacs says: > > # This file is free software, distributed under the terms of the GNU > # General Public License. As a special exception to the GNU General > # Public License, this file may be distributed as part of a program >

Re: Bug in base64, new module base32

Hi Simon, Thanks for accepting the patch. Simon Josefsson writes: There seems to be some memory leaks in the self-tests, although maybe they are inherited from the base64 self-test? The memory leaks seem to be related to the tests. The exact same memory leaks appear in the base64 tests as we

Licence for gnulib.mk slightly vague

Hi, The copy of gnulib.mk in Emacs says: # This file is free software, distributed under the terms of the GNU # General Public License. As a special exception to the GNU General # Public License, this file may be distributed as part of a program # that contains a configuration s

[PATCH] dup2: minor simplification

* m4/dup2.m4 (gl_PREREQ_DUP2): Don't require AC_C_INLINE, as lib/dup2.c no longer uses 'inline'. diff --git a/m4/dup2.m4 b/m4/dup2.m4 index 6385b0c..cd9d254 100644 --- a/m4/dup2.m4 +++ b/m4/dup2.m4 @@ -1,4 +1,4 @@ -#serial 15 +#serial 16 dnl Copyright (C) 2002, 2005, 2007, 2009-2011 Free Software

Re: a saner bootstrap script

On Monday 26 September 2011, Gary V wrote: > Hi Stefano! > Hi Gary, thanks for your quick and detailed answers. > [[Items I agree with elided]] > Ditto. > On 26 Sep 2011, at 17:27, Stefano Lattarini wrote: > > Do you have a diff file to show what you've changed exactly? I'd find that > > really

Re: a saner bootstrap script

On Monday 26 September 2011, Gary V wrote: > >> > > Maybe some code like this should be enough to catch most potential > > erroneous definitions? > > > > case $po_download_command_format in > >*[^%]%s*[^%]%s*) ;; > >*) fatal "invalid format in \$po_download_command_format";; > > esac >

Re: fdopen on MSVC

On 09/24/2011 06:11 PM, Bruno Haible wrote: * modules/fclose-tests (Depends-on): Add fdopen. * modules/fflush-tests (Depends-on): Likewise. * modules/fgetc-tests (Depends-on): Likewise. * modules/fputc-tests (Depends-on): Likewise. * modules/fread-tests (De

Re: a saner bootstrap script

Hi Stefano, On 26 Sep 2011, at 18:06, Stefano Lattarini wrote: > On Monday 26 September 2011, Gary V wrote: @cnindex gnulib_precious @item gnulib_precious Normally, @command{bootstrap} removes any macro-files that are not included by @file{aclocal.m4} before it returns, except

Re: a saner bootstrap script

Hi Stefano! [[Items I agree with elided]] On 26 Sep 2011, at 17:27, Stefano Lattarini wrote: > On Monday 26 September 2011, Gary V wrote: >> On 25 Sep 2011, at 22:55, Stefano Lattarini wrote: >>> On Thursday 22 September 2011, Gary V wrote: Anyone: It's beginning to look as though

Re: a saner bootstrap script

On Monday 26 September 2011, Gary V wrote: > >> @cnindex gnulib_precious > >> @item gnulib_precious > >> Normally, @command{bootstrap} removes any macro-files that are not > >> included by @file{aclocal.m4} before it returns, except for files > >> listed in this variable which are always kept. > >

Re: a saner bootstrap script

Hi Stefano, Thanks again for taking the time to review these files. As before, I've accepted the changes into my copy wherever I haven't commented otherwise below. Since there is no other natural home for the texi file, since I wrote it specifically for gnulib, so I'm attaching the latest versio

Re: a saner bootstrap script

On Monday 26 September 2011, Gary V wrote: > Hi Stefano, > > On 25 Sep 2011, at 22:55, Stefano Lattarini wrote: > > On Thursday 22 September 2011, Gary V wrote: > >> Anyone: > >> > >> It's beginning to look as though all this work is, once again, in very > >> real danger of just slipping quietly

Re: msvc-inval: more options

On Mon, Sep 26, 2011 at 11:06 AM, Paolo Bonzini wrote: > On 09/26/2011 11:01 AM, Bruno Haible wrote: >> >> Additionally, there's a legal problem here: Code like > > Stopped reading here.  Do not include snippets, we _can_ do clean-room > reverse engineering if necessary. > > We can also take code

Re: msvc-inval: more options

On 09/26/2011 11:01 AM, Bruno Haible wrote: Additionally, there's a legal problem here: Code like Stopped reading here. Do not include snippets, we _can_ do clean-room reverse engineering if necessary. We can also take code from Wine's MSVCRT implementation if need be, so that at least it

Re: msvc-inval: more options

> > Particularlyhttp://bugs.python.org/file12953/__pioinfo.patch > > > > A little bit hackhish but seems to work > ... > However, it is bad that these data structures can change for every > version of MSVC. Additionally, there's a legal problem here: Code like +#define IOINFO_L2E 5 +#define IO

Re: msvc-inval: more options

On Mon, Sep 26, 2011 at 10:44 AM, Paolo Bonzini wrote: > On 09/26/2011 10:37 AM, Bastien ROUCARIES wrote: >> >> python >> seehttp://svn.python.org/projects/python/trunk/Modules/posixmodule.c >> seems to have solved a lot the maintenabilty stuff by determining the >> actual size of the structure is

Re: msvc-inval: more options

On 09/26/2011 10:37 AM, Bastien ROUCARIES wrote: python seehttp://svn.python.org/projects/python/trunk/Modules/posixmodule.c seems to have solved a lot the maintenabilty stuff by determining the actual size of the structure is determined at runtime. Still hackish, though slightly better. What

Re: msvc-inval: more options

On Mon, Sep 26, 2011 at 9:01 AM, Paolo Bonzini wrote: > On 09/25/2011 11:46 PM, Bastien ROUCARIES wrote: >> >> Did you seehttp://bugs.python.org/issue4804  ? >> >> Particularlyhttp://bugs.python.org/file12953/__pioinfo.patch >> >> A little bit hackhish but seems to work > > That would provide a lo

Re: Bug in base64, new module base32

Gijs van Tulder writes: > Simon Josefsson wrote: >> Once the copyright papers are resolved, I can commit it >> unless someone else beats me to it. > > Hi. The copyright should be solved now. I've attached the patch for > the base32 module again. (I've changed the RFC reference to point to > the n

Re: a saner bootstrap script

Hi Stefano, On 25 Sep 2011, at 22:55, Stefano Lattarini wrote: > On Thursday 22 September 2011, Gary V wrote: >> Anyone: >> >> It's beginning to look as though all this work is, once again, in very >> real danger of just slipping quietly through the cracks. >> > Hi Gary. While I don't pretend t

Re: msvc-inval: more options

On 09/25/2011 11:46 PM, Bastien ROUCARIES wrote: Did you seehttp://bugs.python.org/issue4804 ? Particularlyhttp://bugs.python.org/file12953/__pioinfo.patch A little bit hackhish but seems to work That would provide a lot more flexibility, including: * the ability to implement O_INHERIT (i.e