Re: source(builtin) and read(2)

[Geoff Clare]

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 members of that list cannot mostly agree on what exactly the
> standard means here, then (once we've figured that out) we should
> reword it so that it is clearer to everybody.

Yes, we should tidy up the wording to eliminate any possible
confusion.  We should be using the wording from the C Standard for
these numerical limits, since most of them are from the C Standard.

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'll submit a defect report.

-- 
Geoff Clare <[EMAIL PROTECTED]>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England

Re: seekable stdin test failure on OS X

[Eric Blake]

-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 bug in your libc.  To confirm, do you have anything like
>> strace
>> or truss that you could run to see what syscalls took place?
> 
> Yes, there is ktrace which outputs the following when running test 68:

> The fork and wait must be the syscmd, and the lseek(0,0,0x1) that returns
> 24 is the seek on stdin from fflush.  What does that mean though?

Not quite - read on.

> 
>   6760 m4   GIO   fd 0 read 24 bytes
>"syscmd(`cat')m4exit(15)
>"
>   6760 m4   RET   read 24/0x18
>   6760 m4   CALL  lseek(0,0,0x1)
>   6760 m4   RET   lseek 24/0x18

OK, this occurs in modules/m4.c, in m4_sysval_flush.  The lseek(0,0,1) is
m4's attempt to learn whether stdin is seekable (and it is, since the
result is 24), prior to calling fflush (since POSIX only requires the
repositioning on seekable files).  But then the fflush/fseek pair makes no
syscalls, which is wrong, since POSIX requires that fflush followed
immediately by fseek discard all unprocessed data on input streams (here,
"m4exit(15)\n" is unprocessed data) and set the position of the underlying
fd.  I would submit a bug to the MacOS people.  In the case of cygwin,
this shows up as another call to lseek, putting the offset back to 13.

>   6760 m4   CALL  sigaction(0x2,0xbfffece0,0xbfffed3c)
...
>   6760 m4   RET   sigprocmask 0

Yes, this sequence was the syscmd.  And cat should have seen the text
"m4exit(15)\n", seeing as how the fflush was supposed to reset the
underlying fd location back to the unprocessed data,...

>   6760 m4   CALL  fstat(0x1,0xbfffecc0)
>   6760 m4   RET   fstat 0
>   6760 m4   CALL  fstat(0x2,0xbfffec60)
>   6760 m4   RET   fstat 0
>   6760 m4   CALL  lseek(0,0,0x1)
>   6760 m4   RET   lseek 24/0x18

This lseek was correct - after invoking a child process, the fd's
underlying position may have been changed by the child, so libc must
indeed rediscover where to resume reading from.  In this case, since cat
should have consumed the rest of the input file, there should be nothing
else available for reading from stdin, and m4 should exit with status 0
for normal end of file processing, rather than 15 due to reparsing data
consumed by the child process.

> 
>> We may end up having to write an autoconf test that can detect this
>> brokenness in libc, and based on that test, add additional calls to fseek
>> if using fflush alone is inadequate for m4 to follow the POSIX rules of
>> how to handle seekable input streams.
> 
> Bleh!

I agree.  But will it even work?  m4 already called fseek, but currently
it just discarded the results; can you step through m4_sysval_flush to
determine if the fseek was accurately returning the offset in the middle
of the input rather than at the end?  If it does work, how many other
gnulib-using programs would benefit from a fix?

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEQQl84KuGfSFAYARAsCOAKDOG3+VmSX3B6uuWEXT2KLRjmbcmQCbB0Mp
Hm/U+VRAJAvhDvOgtdodwlU=
=CJBD
-END PGP SIGNATURE-

Re: seekable stdin test failure on OS X

[Gary V. Vaughan]

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  
the file
   511   pointer location on a non-seekable file).  It also  
requires that
   512   fflush() followed by fseek() on an input file set the  
underlying
   513   file pointer.  However, fflush() on a non-seekable file  
can lose
   514   buffered data, which we might otherwise want to process  
after
   515   syscmd.  Hence, we must check whether stdin is  
seekable.  We must
   516   also be tolerant of operating with stdin closed, so we  
don't
   517   report any failures in this attempt.  The stdio-safer  
module and
   518   friends are essential, so that if stdin was closed,  
this lseek is
   519   not on some other file that we have since opened.   
Mingw has bugs
   520   when using fseek on text files, so we only strive for  
POSIX

   521   behavior when we detect a UNIX environment.  */
   522  #if UNIX
   523if (lseek (STDIN_FILENO, 0, SEEK_CUR) >= 0
   524&& fflush (stdin) == 0)
   525  {
   526fseek (stdin, 0, SEEK_CUR);
   527  }
   528  #endif /* UNIX */
   529  }

On 2 Apr 2007, at 14:24, Eric Blake wrote:

m4 already called fseek, but currently
it just discarded the results; can you step through m4_sysval_flush to
determine if the fseek was accurately returning the offset in the  
middle

of the input rather than at the end?


Okay, at line 524 fflush returns -1 and sets errno to EBADF.

Looking at the man page for Mac OS fflush, it is only supposed to work
for output streams where it flushes the write buffer.  The equivalent
function for input streams is fpurge.  And indeed, if I change 524 to
call "fpurge (stdin)", the test passes.


If it does work, how many other
gnulib-using programs would benefit from a fix?


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?

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912






PGP.sig
Description: This is a digitally signed message part

Re: source(builtin) and read(2)

[Matthew Woehlke]

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 " 
is to me unambiguous. If you want to be /really/ unambiguous I would 
even add the word "representable" to clearly indicate that you are 
talking about architecture-mandated limits, not arbitrary OS limits.


--
Matthew
Vs lbh pna ernq guvf jvgubhg fbsgjner, lbh ner n FREVBHF areq! -- 
Nqncgrq sebz Znggurj Jva (ivz-qri znvyvat yvfg)

Re: new module 'iconv_open'

[Eric Blake]

Bruno Haible  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 encoding names to the implementation specific
>  ones (not needed on Solaris).

This change breaks compiling the latest git coreutils on at least cygwin:

> 
> GPERF = gperf
> iconv_open-aix.h: iconv_open-aix.gperf
>   $(GPERF) -m 10 iconv_open-aix.gperf > [EMAIL PROTECTED]
>   mv [EMAIL PROTECTED] $@

make[1]: Entering directory `/home/eblake/coreutils/lib'
gperf -m 10 iconv_open-aix.gperf > iconv_open-aix.h-t
gperf: invalid option -- m
Usage: gperf [-cCdDef[num]
FGhHiIjkKlLnNorsStTvWZ7] [input-file]
Try `gperf --help' for more information.
make[1]: *** [iconv_open-aix.h] Error 1

gperf --version
GNU gperf 2.7.2

gperf is not on the list of widely available programs, so it must not be 
invoked by a normal user when compiling a tarball, but requiring maintainers to 
have gperf available might be reasonable if you could rework this to use a 
command line that will work with commonly-installed gperf versions.  Which 
version did you test with?

-- 
Eric Blake

Re: new module 'iconv_open'

[Simon Josefsson]

Eric Blake <[EMAIL PROTECTED]> writes:

> Bruno Haible  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 encoding names to the implementation specific
>>  ones (not needed on Solaris).
>
> This change breaks compiling the latest git coreutils on at least cygwin:
>
>> 
>> GPERF = gperf
>> iconv_open-aix.h: iconv_open-aix.gperf
>>  $(GPERF) -m 10 iconv_open-aix.gperf > [EMAIL PROTECTED]
>>  mv [EMAIL PROTECTED] $@
>
> make[1]: Entering directory `/home/eblake/coreutils/lib'
> gperf -m 10 iconv_open-aix.gperf > iconv_open-aix.h-t
> gperf: invalid option -- m
> Usage: gperf [-cCdDef[num]
> FGhHiIjkKlLnN name>orsStTvWZ7] [input-file]
> Try `gperf --help' for more information.
> make[1]: *** [iconv_open-aix.h] Error 1
>
> gperf --version
> GNU gperf 2.7.2
>
> gperf is not on the list of widely available programs, so it must not be 
> invoked by a normal user when compiling a tarball, but requiring maintainers 
> to 
> have gperf available might be reasonable if you could rework this to use a 
> command line that will work with commonly-installed gperf versions.  Which 
> version did you test with?

It works here with gperf 3.0.2.  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 > iconv_open-aix.h-t
/bin/sh: gperf: command not found
make[2]: *** [iconv_open-aix.h] Error 127

No warnings about missing gperf during ./configure.  I think the M4
code should test for a gperf tool, using AM_MISSING_PROG or similar.

/Simon

Re: seekable stdin test failure on OS X

[Paul Eggert]

"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  (along with __fpending and friends).  The
documentation says it "discards any pending buffered I/O on the
stream."  It returns void.

Re: seekable stdin test failure on OS X

[Gary V. Vaughan]

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 called __fpurge and is declared
in  (along with __fpending and friends).  The
documentation says it "discards any pending buffered I/O on the
stream."  It returns void.


__fpurge appears to be supported on Linux too:

  http://www.die.net/doc/linux/man/man3/fpurge.3.html

On Mac OS there doesn't seem to be any evidence of an __fpurge function:

  ] man __fpurge
  No manual entry for __fpurge
  ] find /usr/include -name '*.h' -exec fgrep -l __fpurge {} \;
  ] uname -a
  Darwin Garys-MacBook.local 8.9.1 Darwin Kernel Version 8.9.1: Thu  
Feb 22 20:55:00 PST 2007; root:xnu-792.18.15~1/RELEASE_I386 i386 i386


Even on Linux, the fflush man page doesn't mention input streams:

  http://www.die.net/doc/linux/man/man3/fflush.3.html

So it seems that using fflush(stdin) is probably the wrong thing
to do altogether for a portable application.

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912





PGP.sig
Description: This is a digitally signed message part

Re: seekable stdin test failure on OS X

[Eric Blake-1]

> Even on Linux, the fflush man page doesn't mention input streams:
> 
>http://www.die.net/doc/linux/man/man3/fflush.3.html
> 
> So it seems that using fflush(stdin) is probably the wrong thing
> to do altogether for a portable application.

On the contrary, it makes it sound like we write a gnulib module
that implements POSIX semantics of fflush, which creates a
function rpl_fflush that calls fpurge or __fpurge under the hood
when the regular fflush is broken on input streams; then portable
applications can assume POSIX semantics for fflush.

-- 
Eric Blake

-- 
View this message in context: 
http://www.nabble.com/Re%3A-seekable-stdin-test-failure-on-OS-X-tf3505729.html#a9794974
Sent from the Gnulib mailing list archive at Nabble.com.

Re: seekable stdin test failure on OS X

[Ben Pfaff]

"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]

Re: seekable stdin test failure on OS X

[Paul Eggert]

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 fflush (stdin) should
flush the input buffer and (on seekable devices) restore the input
position on the underyling file descriptor to match the position in
the stream.  At some point in the mid-1990s this requirement was
weakened to be more like (but not exactly like) ISO C89.  However, in
the latest POSIX it's stronger again, and is more like the late 1980s.

Part of the problem is that this area is so complicated that almost
nobody other than standards nerds understands the wording.  (And most
of them probably don't understand it either.)

Anyway, for what it's worth I think fflush (stdin) should behave like
1988 POSIX and glibc, at least for apps that care about this sort of
thing.

Re: seekable stdin test failure on OS X

[Ben Pfaff]

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 (stdin) should
> flush the input buffer and (on seekable devices) restore the input
> position on the underyling file descriptor to match the position in
> the stream.  At some point in the mid-1990s this requirement was
> weakened to be more like (but not exactly like) ISO C89.  However, in
> the latest POSIX it's stronger again, and is more like the late 1980s.

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 least it doesn't on the page dedicated to
fflush.

> Anyway, for what it's worth I think fflush (stdin) should behave like
> 1988 POSIX and glibc, at least for apps that care about this sort of
> thing.

If apps want that behavior then it entirely makes sense to
implement it (and I really shouldn't have stuck my oar in).

I'm surprised that glibc implements this behavior for fflush on
input streams: the glibc manual I have here doesn't mention it.
But I can see in the libio sources that glibc does do it.
-- 
Ben Pfaff
[EMAIL PROTECTED]

Re: seekable stdin test failure on OS X

[Eric Blake]

-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 remember it; I haven't checked the actual documents.  In
> the late 1980s the POSIX committee decided that fflush (stdin) should
> flush the input buffer and (on seekable devices) restore the input
> position on the underyling file descriptor to match the position in
> the stream.

I don't have access to the early POSIX wording to verify this, but think
you are right.

>  At some point in the mid-1990s this requirement was
> weakened to be more like (but not exactly like) ISO C89.

This part is true - the current POSIX is silent about whether
fflush(stdin) is supposed to work, but is explicit that fseek() is
supposed to set the position of the underlying fd if it immediately
follows fflush() without any limitation on whether the fflush/fseek pair
is on an input or an output stream.  So indirectly, the fseek requirement
implies that fflush(stdin) is still valid in the current POSIX.

>  However, in
> the latest POSIX it's stronger again, and is more like the late 1980s.

Yes - the current proposed wording adds this explicit C extension shaded
section to fflush:

CX For a stream open for reading, if the file is not already at EOF, and
the file is one capable of seeking, the file offset of the underlying open
file description shall be adjusted so that the next operation on the open
file description deals with the byte after the last one read from or
written to the stream being flushed.

> 
> Part of the problem is that this area is so complicated that almost
> nobody other than standards nerds understands the wording.  (And most
> of them probably don't understand it either.)
> 
> Anyway, for what it's worth I think fflush (stdin) should behave like
> 1988 POSIX and glibc, at least for apps that care about this sort of
> thing.

Which is why I think a gnulib module for fflush is the right thing to do;
where it can call __fpurge under the hood on systems that reject
fflush(stdin).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEVPz84KuGfSFAYARAqQaAKCdhLhuvy3QKcnVHL6mtkk0Yru29wCgwr3t
l6FYhJZN4CrXgtIARCP3+PM=
=W9Qk
-END PGP SIGNATURE-

Re: seekable stdin test failure on OS X

[Eric Blake]

-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 least it doesn't on the page dedicated to
> fflush.

It is in draft form, and you have to be a member of the Austin group to
have read access to it.  Membership is free:
http://www.opengroup.org/austin/lists.html

Draft 2 is closed, and draft 3 is not yet ready for comments; it is
anticipated to have at least draft 4 before the next version of POSIX
becomes binding.

> 
> I'm surprised that glibc implements this behavior for fflush on
> input streams: the glibc manual I have here doesn't mention it.

That's because the man page copies the (weaker) wording from the existing
POSIX spec, which is rather vague in that area.

> But I can see in the libio sources that glibc does do it.

Also, the newlib library (the basis of cygwin) was patched in the last
year to do so.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEVSE84KuGfSFAYARAhy3AJ9BSNNjdYcov2ym9PNSbZfuk9GuyACgyI+w
CH9Jj9xatKnDlnzcdtt3RKg=
=0X2H
-END PGP SIGNATURE-

Re: new module 'iconv_open'

[Bruno Haible]

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 the Makefile rules guarantee this: The generated iconv_open-*.h
files are listed in EXTRA_DIST, which will cause them to be present in the
tarballs. But you are probably working off the coreutils CVS, therefore
you need up-to-date tools. Just like with 'bison'.

> but requiring maintainers to have gperf available might be reasonable if
> you could rework this to use a command line that will work with
> commonly-installed gperf versions.

I can only feel sorry for the users of distros where the distro packagers
don't upgrade a program to a new version even in 4 years. And gperf-3.0.x
is _really_ not hard to upgrade: it compiles out of the box on all platforms
and is backward compatible with earlier versions.

Bruno

Re: new module 'iconv_open'

[Bruno Haible]

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 > iconv_open-aix.h-t
> /bin/sh: gperf: command not found
> make[2]: *** [iconv_open-aix.h] Error 127

Yes, bison, flex, and gperf are the three common tools for code generation.

> No warnings about missing gperf during ./configure.  I think the M4
> code should test for a gperf tool, using AM_MISSING_PROG or similar.

It could, in theory. But what should the Makefile rule do if 'gperf' was not
found?
  - If the iconv_open-aix.h file does not yet exist, it simply cannot proceed.
(Except on AIX... - Should I make the dependencies platform dependent?)
  - If the iconv_open-aix.h file exists but is older, what to do? Emit a
warning and compile the old .h file?

Bruno

update intdiv0.m4

[Bruno Haible]

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 00:07:50 -
@@ -51,7 +51,7 @@
   # Guess based on the CPU.
 changequote(,)dnl
   case "$host_cpu" in
-alpha* | i[34567]86 | m68k | s390*)
+alpha* | i[34567]86 | x86_64 | m68k | s390*)
   gt_cv_int_divbyzero_sigfpe="guessing yes";;
 *)
   gt_cv_int_divbyzero_sigfpe="guessing no";;

Re: EXC_I386_DIV (divide by zero)

[Bruno Haible]

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 0.16.1:
> 
> 
> 2007-03-31 22:29:46 -0500
> 
> EXC_ARITHMETIC (0x0003)
> EXC_I386_DIV (divide by zero)
> 
> Thread 0 Crashed:
> 0main + 56
> 1_start + 216
> 2start + 41

Thank you for the report. I'm applying this patch, which should have the
effect of avoiding the dialog box, without affecting the result of the test.

> I do not see a GUI error box appear when configuring gettext 0.16.1  
> on Mac OS X 10.4.9 on a PowerBook G4 (with PowerPC G4 processor),  
> though it's possible the machine configurations differ slightly.

The PowerPC and x86 processors behave differently upon integer division
by zero.

> It would be better if no GUI dialog boxes appeared during the  
> configuration of command-line software. I don't think any other  
> software I've compiled on this MacBook Pro has popped up GUI error  
> boxes while being compiled.

Of course, I agree.

> If this problem is already known, and there is a public bug database  
> where I could have found it, please let me know where it is. The only  
> bug database I found was this one, and the bug does not seem to be  
> reported there:
> 
> http://savannah.gnu.org/bugs/?group=gettext

Thank you for having looked at the bug tracker or googled a bit before
reporting. And thank you for the report in the first place.

Bruno


2007-04-02  Bruno Haible  <[EMAIL PROTECTED]>

* m4/intdiv0.m4 (gt_INTDIV0): Avoid performing the test for real on
x86 or x86_64 platforms running MacOS X.
Reported by Ryan Schmidt <@ryandesign.com>.

*** m4/intdiv0.m4   3 Apr 2007 00:12:05 -   1.6
--- m4/intdiv0.m4   3 Apr 2007 00:18:42 -
***
*** 14,20 
AC_CACHE_CHECK([whether integer division by zero raises SIGFPE],
  gt_cv_int_divbyzero_sigfpe,
  [
!   AC_TRY_RUN([
  #include 
  #include 
  
--- 14,35 
AC_CACHE_CHECK([whether integer division by zero raises SIGFPE],
  gt_cv_int_divbyzero_sigfpe,
  [
!   gt_cv_int_divbyzero_sigfpe=
! changequote(,)dnl
!   case "$host_os" in
! macos* | darwin[6-9]* | darwin[1-9][0-9]*)
!   # On MacOS X 10.2 or newer, just assume the same as when cross-
!   # compiling. If we were to perform the real test, 1 Crash Report
!   # dialog window would pop up.
!   case "$host_cpu" in
! i[34567]86 | x86_64)
!   gt_cv_int_divbyzero_sigfpe="guessing yes" ;;
!   esac
!   ;;
!   esac
! changequote([,])dnl
!   if test -z "$gt_cv_int_divbyzero_sigfpe"; then
! AC_TRY_RUN([
  #include 
  #include 
  
***
*** 47,63 
exit (1);
  }
  ], gt_cv_int_divbyzero_sigfpe=yes, gt_cv_int_divbyzero_sigfpe=no,
! [
!   # Guess based on the CPU.
  changequote(,)dnl
!   case "$host_cpu" in
! alpha* | i[34567]86 | x86_64 | m68k | s390*)
!   gt_cv_int_divbyzero_sigfpe="guessing yes";;
! *)
!   gt_cv_int_divbyzero_sigfpe="guessing no";;
!   esac
  changequote([,])dnl
! ])
  ])
case "$gt_cv_int_divbyzero_sigfpe" in
  *yes) value=1;;
--- 62,79 
exit (1);
  }
  ], gt_cv_int_divbyzero_sigfpe=yes, gt_cv_int_divbyzero_sigfpe=no,
!   [
! # Guess based on the CPU.
  changequote(,)dnl
! case "$host_cpu" in
!   alpha* | i[34567]86 | x86_64 | m68k | s390*)
! gt_cv_int_divbyzero_sigfpe="guessing yes";;
!   *)
! gt_cv_int_divbyzero_sigfpe="guessing no";;
! esac
  changequote([,])dnl
!   ])
!   fi
  ])
case "$gt_cv_int_divbyzero_sigfpe" in
  *yes) value=1;;

Re: EX_OK collision

[Bruno Haible]

Simon Josefsson wrote:
> > How about (b)?  It seems the simplest.
> >
> >>   (b) Create a replacement  that does
> >>
> >>  #include 
> >>  #undef EX_OK
> >>  #include 
> 
> Yes, I think so too. ...

OK, after you both agreed, I commit this:


2007-04-02  Bruno Haible  <[EMAIL PROTECTED]>

* lib/sysexit_.h (EX_OK): Disable the EX_OK definition from 
on IRIX.

*** lib/sysexit_.h  30 Mar 2007 23:56:06 -  1.5
--- lib/sysexit_.h  3 Apr 2007 00:45:38 -
***
*** 22,27 
--- 22,35 
  
  #if @HAVE_SYSEXITS_H@
  
+ /* IRIX 6.5 has an  that defines a macro EX_OK with a nonzero
+value.  Override it.  See
+  */
+ # ifdef __sgi
+ #  include 
+ #  undef EX_OK
+ # endif
+ 
  # include @ABSOLUTE_SYSEXITS_H@
  
  /* HP-UX 11  ends at EX_NOPERM.  */

Re: new module 'iconv_open'

[John Darrington]

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 > iconv_open-aix.h-t
 > /bin/sh: gperf: command not found
 > make[2]: *** [iconv_open-aix.h] Error 127

This was an unexpected surprise for me too.
 
 Yes, bison, flex, and gperf are the three common tools for code generation.
 
 > No warnings about missing gperf during ./configure.  I think the M4
 > code should test for a gperf tool, using AM_MISSING_PROG or
 > similar.

I agree.
 
 It could, in theory. But what should the Makefile rule do if 'gperf' was 
not
 found?
   - If the iconv_open-aix.h file does not yet exist, it simply cannot 
proceed.
 (Except on AIX... - Should I make the dependencies platform dependent?)
   - If the iconv_open-aix.h file exists but is older, what to do? Emit a
 warning and compile the old .h file?
 
I don't fully understand all the issues here, but at the very least,
./configure could show a warning if gperf is not found or is too old.

J'
 
-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




signature.asc
Description: Digital signature

test-stat-time failure on FreeBSD 6

[Bruno Haible]

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 /lib/libc.so.6
#2  0x28126014 in abort () from /lib/libc.so.6
#3  0x08048a44 in test_birthtime (statinfo=0xbfbfeb40, modtimes=0xbfbfeb20, 
birthtimes=0xbfbfeb00) at test-stat-time.c:143
#4  0x08048b43 in main () at test-stat-time.c:170
(gdb) up 3
#3  0x08048a44 in test_birthtime (statinfo=0xbfbfeb40, modtimes=0xbfbfeb20, 
birthtimes=0xbfbfeb00) at test-stat-time.c:143
143   ASSERT (modtimes[0].tv_sec < birthtimes[1].tv_sec); /* mtime(stamp1) 
< birthtime(renamed) */
(gdb) print modtimes[0]
$3 = {tv_sec = 1175565336, tv_nsec = 0}
(gdb) print modtimes[1]
$4 = {tv_sec = 1175565338, tv_nsec = 0}
(gdb) print modtimes[2]
$5 = {tv_sec = 1175565340, tv_nsec = 0}
(gdb) print modtimes[3]
$6 = {tv_sec = 1175565344, tv_nsec = 0}
(gdb) print birthtimes[0]
$7 = {tv_sec = 0, tv_nsec = 0}
(gdb) print birthtimes[1]
$8 = {tv_sec = 0, tv_nsec = 0}
(gdb) print birthtimes[2]
$9 = {tv_sec = 0, tv_nsec = 0}
(gdb) print birthtimes[3]
$10 = {tv_sec = 0, tv_nsec = 0}

Bruno

Re: new module 'iconv_open'

[Bruno Haible]

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

missing dependency in *printf

[Eric Blake]

-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, please use m4_pattern_allow.
  See the Autoconf documentation.

Fixed thusly:

2007-04-02  Eric Blake  <[EMAIL PROTECTED]>

* modules/printf-frexpl (Depends-on): Depend on ldexpl.

Index: modules/printf-frexpl
===
RCS file: /sources/gnulib/gnulib/modules/printf-frexpl,v
retrieving revision 1.4
diff -u -p -r1.4 printf-frexpl
- --- modules/printf-frexpl   25 Mar 2007 02:30:04 -  1.4
+++ modules/printf-frexpl   3 Apr 2007 03:29:48 -
@@ -10,8 +10,9 @@ m4/printf-frexpl.m4
 m4/longdouble.m4

 Depends-on:
- -math
 fpucw
+ldexpl
+math

 configure.ac:
 gl_FUNC_PRINTF_FREXPL

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEctV84KuGfSFAYARAo+QAJ9uyyxZxRhpdIY6pMPxoIyUI7zjoACfTF91
rJ//+TKZknMMn8u/28bc7dg=
=Im7C
-END PGP SIGNATURE-

Re: missing dependency in *printf

[Eric Blake]

-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
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.

And another one:

libtool: compile:  gcc -std=gnu99 -I. -I../../gnu -I../intl -g2 -Wall
- -Werror -MT ldexpl.lo -MD -MP -MF .deps/ldexpl.Tpo -c ../../gnu/ldexpl.c
- -DDLL_EXPORT -DPIC -o .libs/ldexpl.o
../../gnu/ldexpl.c:29:20: isnanl.h: No such file or directory
../../gnu/ldexpl.c: In function `ldexpl':
../../gnu/ldexpl.c:41: warning: implicit declaration of function `isnanl'
make[3]: *** [ldexpl.lo] Error 1

2007-04-02  Eric Blake  <[EMAIL PROTECTED]>

* lib/ldexpl.c (includes): Avoid libm.

diff --git a/lib/ldexpl.c b/lib/ldexpl.c
index bb16be6..bce2a08 100644
- --- a/lib/ldexpl.c
+++ b/lib/ldexpl.c
@@ -26,7 +26,7 @@

 #include 
 #include "fpucw.h"
- -#include "isnanl.h"
+#include "isnanl-nolibm.h"

 long double
 ldexpl(long double x, int exp)

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEc9+84KuGfSFAYARAhxZAJ0YniE7CM1WCf2rSCuZ5X/wAs1uKACbBGx8
a3nttbJ9H9o1ZNkb93y74Hs=
=eifY
-END PGP SIGNATURE-

Re: new module 'iconv_open'

[Ben Pfaff]

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 a single configure
run, instead of just failing the configure run after finding the
first missing prerequisite library.  It would be a natural
extension to apply this to helper tools such as gperf.
-- 
"Unix... is not so much a product
 as it is a painstakingly compiled oral history
 of the hacker subculture."
--Neal Stephenson