I installed this, to simplify testing getpass implementations.
Index: ChangeLog
===
RCS file: /cvsroot/gnulib/gnulib/ChangeLog,v
retrieving revision 1.340
diff -u -p -r1.340 ChangeLog
--- ChangeLog 24 Aug 2005 06:23:16 -
Simon Josefsson wrote:
How about this patch?
2005-08-23 Simon Josefsson [EMAIL PROTECTED]
* getpass.c (__fsetlocking): Define to nothing unless we have it.
2005-08-23 Simon Josefsson [EMAIL PROTECTED]
* getpass.m4: Check for __fsetlocking.
Looks good to me.
Bruno
Paul Eggert wrote:
Is there some simple
way that we can work around this in the regex code, without having to
make wholesale changes? For example, can we surround all the code
with extern C { ... } when compiling with C++?
No, extern C only affects the name mangling of symbols and the
Oskar Liljeblad wrote:
Here's what getdelim in Gnulib returns:
=0, errno undefined, feof (getc returned EOF, reached end of file)
=0, errno!=0, ferror (getc returned EOF, read failed)
Actually I think the glibc doc means that -1 is returned if EOF or read
failure occurs before the
This builds on Mingw32, uClinux/uClibc, Debian, NetBSD, OSF/1, HPUX,
Solaris. The current one doesn't work on Mingw32 (that doesn't have
the tty concept) nor uClinux/uClibc (doesn't have fsetlocking). The
recently installed self-test work on Mingw32 and Debian. Martin has
submitted copyright
Hello,
On Sat, Aug 13, 2005 at 03:20:56PM +0200, Oskar Liljeblad wrote:
For example, I was looking for translations
for lib/regcomp.c in Gnulib. Is there any project that has those
translations, or are they completely new?
the regex module came from GNU libc, glibc. I guess that project is
Jim Meyering wrote:
Note that POSIX *does* require a failed malloc call to set errno to
ENOMEM, albeit with CX shading (meaning IEEE Std 1003.1-2001).
http://www.opengroup.org/susv3xsh/malloc.html
Let's try not to let substandard systems dictate interface design.
If some system has a poor
On Wednesday, August 24, 2005 at 15:52, Bruno Haible wrote:
I'm not in favour of a wrapper around malloc(), that would add overhead to
a function called as frequently as malloc(), just to set 'errno'.
ISO C 99 is not a substandard, and Windows malloc() is not poor just
because it does not
Bruno Haible [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
Note that POSIX *does* require a failed malloc call to set errno to
ENOMEM, albeit with CX shading (meaning IEEE Std 1003.1-2001).
http://www.opengroup.org/susv3xsh/malloc.html
Let's try not to let substandard systems dictate
Jim Meyering wrote:
... a prescribed norm: relatively-recent POSIX.
...
My point is that Gnulib development should not be held hostage to a
system that is behind the standards curve.
I disagree. Gnulib's purpose is to provide portability across the
mainstream systems, _regardless_ whether
Martin Lambers wrote:
Back in February, I suggested to add EX_OK to the sysexit module
(http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg00042.html).
Is there a reason not to do that?
Regards,
Martin
--- sysexit_h.orig2005-08-24 17:47:34.966600112 +0200
+++ sysexit_h
On Wed, 24. Aug 2005, 18:39:02 +0200, Bruno Haible wrote:
Martin Lambers wrote:
Back in February, I suggested to add EX_OK to the sysexit module
(http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg00042.html).
Is there a reason not to do that?
It sounds OK to do that; glibc's
Jim Meyering [EMAIL PROTECTED] writes:
I'll hold off on the commit until Paul signs off on it.
That looks good to me. Thanks for doing the merge.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
I've just committed that patch.
Jim Meyering [EMAIL PROTECTED] wrote:
...
Thanks for reporting that.
With the following changes,
./gnulib-tool --test fts
once again passes.
2005-08-24 Jim Meyering [EMAIL PROTECTED]
* modules/fcntl-safer: New module.
* modules/fts
Simon Josefsson [EMAIL PROTECTED] writes:
Can't the sysexit.h file assume C89, and use EXIT_SUCCESS without
requiring the exit module? It seems a somewhat complicated dependency
for something everyone already know is 0.
C89 says that 0 is also a successful exit code. Is there an
advantage
I installed this to patch another POSIX incompatibility with regex,
and filed glibc bug 1240.
2005-08-24 Paul Eggert [EMAIL PROTECTED]
* config/srclist.txt: Add glibc bug 1240.
* lib/regcomp.c (regerror): 2nd arg is 'restrict', as per POSIX.
* lib/regex.h (regerror):
Ben Pfaff [EMAIL PROTECTED] writes:
Is there an advantage to defining EX_OK to EXIT_SUCCESS over
defining it to 0?
I can't think of any. Let's please just define it to 0; it's simpler
and less likely to cause trouble.
I also like Simon's suggestion of defining EXIT_SUCCESS and
EXIT_FAILURE
17 matches
Mail list logo
