Paul Eggert said:
Fine, but the point is that there's no portable way for an application
to determine whether adding 1 to a ssize_t variable will have normal
execution if the variable's value is SSIZE_MAX. This is regardless
of whether SSIZE_MAX is the maximum value representable in a
James Youngman [EMAIL PROTECTED] wrote, on 31 Mar 2007:
It seems to me that there is a certain amount of
(confusion|disagreement) among members of the austin-group-l mailing
list, who are, almost by definition, connoisseurs of standards wording
and distinguishers of fine points.
If the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gary V. Vaughan on 4/2/2007 6:44 AM:
Hi Eric,
Hi Gary, and adding gnulib readers,
Yuck. I think this means that on your platform, fflush(stdin) is
neglecting to reset the underlying fd position when stdin is seekable,
which is a
Hi Eric,
Here is the relevant code from modules/m4.c in CVS HEAD:
508/* POSIX requires that if m4 doesn't consume all input,
but stdin is
509 opened on a seekable file, that the file pointer be
left at the
510 next character on exit (but places no restrictions on
Geoff Clare wrote:
Ironically, it is the wording for SSIZE_MAX that is closest to
being right and the others that all need to change, as the wording
in the C Standard is maximum value for an object of type .
I still think that's the *worst* wording. Maximum value of type foo
is to me
Bruno Haible bruno at clisp.org writes:
Some proprietary iconv() implementations (IRIX, OSF/1, Solaris) are
actually usable if
1. one is willing to do an indirect conversion (through UTF-8) if a direct
conversion between two encodings doesn't exist,
2. one maps the standardized
Eric Blake [EMAIL PROTECTED] writes:
Bruno Haible bruno at clisp.org writes:
Some proprietary iconv() implementations (IRIX, OSF/1, Solaris) are
actually usable if
1. one is willing to do an indirect conversion (through UTF-8) if a direct
conversion between two encodings doesn't
Gary V. Vaughan [EMAIL PROTECTED] writes:
At worst we need an autoconf test to see whether fflush works on stdin,
but maybe all that is needed is to call fpurge when present, and
fallback to fflush otherwise?
For what it's worth, on Solaris it's called __fpurge and is declared
in stdio_ext.h
On 2 Apr 2007, at 17:24, Paul Eggert wrote:
Gary V. Vaughan [EMAIL PROTECTED] writes:
At worst we need an autoconf test to see whether fflush works on
stdin,
but maybe all that is needed is to call fpurge when present, and
fallback to fflush otherwise?
For what it's worth, on Solaris it's
Gary V. Vaughan [EMAIL PROTECTED] writes:
So it seems that using fflush(stdin) is probably the wrong thing
to do altogether for a portable application.
ISO C89 and C99 say that fflush(stdin) yields undefined behavior,
so I'm inclined to agree.
--
Ben Pfaff
[EMAIL PROTECTED]
Ben Pfaff [EMAIL PROTECTED] writes:
ISO C89 and C99 say that fflush(stdin) yields undefined behavior,
so I'm inclined to agree.
It's more complicated than that, I'm afraid.
Here's how I remember it; I haven't checked the actual documents. In
the late 1980s the POSIX committee decided that
Paul Eggert [EMAIL PROTECTED] writes:
Ben Pfaff [EMAIL PROTECTED] writes:
ISO C89 and C99 say that fflush(stdin) yields undefined behavior,
so I'm inclined to agree.
Here's how I remember it; I haven't checked the actual documents. In
the late 1980s the POSIX committee decided that fflush
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 4/2/2007 12:41 PM:
Ben Pfaff [EMAIL PROTECTED] writes:
ISO C89 and C99 say that fflush(stdin) yields undefined behavior,
so I'm inclined to agree.
It's more complicated than that, I'm afraid.
Here's how I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ben Pfaff on 4/2/2007 12:56 PM:
Is there a version of POSIX newer than The Open Group Base
Specifications Issue 6: IEEE Std 1003.1, 2004 Edition? This
version doesn't say anything about the behavior of fflush for
input streams, or at
Eric Blake wrote:
gperf --version
GNU gperf 2.7.2
Come on! gperf 3.0.1 was released four years ago, and you are still using its
seven year old predecessor?
gperf is not on the list of widely available programs, so it must not be
invoked by a normal user when compiling a tarball
Right. And
Regarding integer division by 0, x86_64 behaves like i386.
2007-04-02 Bruno Haible [EMAIL PROTECTED]
* m4/intdiv0.m4 (gt_INTDIV0): When cross-compiling, treat x86_64 like
i386.
--- m4/intdiv0.m4 13 Feb 2007 22:49:23 - 1.5
+++ m4/intdiv0.m4 3 Apr 2007
Hello,
Ryan Schmidt wrote:
Hi. I hope this is the right place to report gettext bugs.
Yes, you're welcome.
On a MacBook Pro (with Intel Core 2 Duo processor) with Mac OS X
10.4.9, a GUI dialog box containing the following error appears twice
during the configuration phase of gettext
Simon Josefsson wrote:
How about (b)? It seems the simplest.
(b) Create a replacement sysexits.h that does
#include unistd.h
#undef EX_OK
#include /usr/include/sysexits.h
Yes, I think so too. ...
OK, after you both agreed, I commit this:
2007-04-02
On Tue, Apr 03, 2007 at 12:43:19AM +0200, Bruno Haible wrote:
Simon Josefsson wrote:
Well, at least after I installed
gperf, before that I got this error during build:
make[2]: Entering directory `/home/jas/src/libidn/lib/gl'
gperf -m 10 iconv_open-aix.gperf
Hello James,
On FreeBSD/x86 6.1, on a NFS mount, the test-stat-time test fails:
$ gdb test-stat-time
...
(gdb) run
Program received signal SIGABRT, Aborted.
0x28127363 in kill () from /lib/libc.so.6
(gdb) where
#0 0x28127363 in kill () from /lib/libc.so.6
#1 0x28127300 in raise () from
John Darrington wrote:
./configure could show a warning if gperf is not found or is too old.
What do you gain by knowing this at configure time, rather than at make
time, a little later? To proceed with the build, you need to install gperf
anyway.
Bruno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In trying to use sprintf-posix in m4, I came across this:
cd .. /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf
configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WORKS
If this token and others are legitimate,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/2/2007 9:34 PM:
In trying to use sprintf-posix in m4, I came across this:
cd .. /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf
configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WORKS
Bruno Haible [EMAIL PROTECTED] writes:
What do you gain by knowing this at configure time, rather than at make
time, a little later? To proceed with the build, you need to install gperf
anyway.
In PSPP, we've been trying to display all the missing
prerequisite libraries together at the end of
24 matches
Mail list logo
