Hello Bruno, all,
* Bruno Haible wrote on Sat, Feb 24, 2007 at 01:30:53AM CET:
[...]
> + @case $(PERL) in\
You probably want to put that in quotes, so $(PERL) expanding to two
words won't cause a syntax error.
> + *"/missing "*) ;;
Bruno Haible <[EMAIL PROTECTED]> wrote:
> 2007-02-23 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/perl.m4 (gl_PERL): Require version 5.005, not 5.003. Needed for
> help2man.
> * man/Makefile.am (.x.1): If the autoconf test has determined that
> perl is missing or not a suffic
Bruno Haible <[EMAIL PROTECTED]> writes:
> So it's an endless loop in lines 71-72 of nanosleep.c.
That's weird. I guess we should mark nanosleep as not working on your
platform. I installed the following patch, which should be harmless
on valid nanosleep hosts; does it detect the bug on your pl
Bruno Haible <[EMAIL PROTECTED]> writes:
> "For testing portability, invoke 'gnulib-tool --import check-portability'
>(or check-portability-unix if mingw is not among your portability targets),
>then compile the program and look at the link time warnings. Use
>gnulib-tool --import wi
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Bruno Haible wrote on Sat, Feb 24, 2007 at 01:30:53AM CET:
> [...]
>> +@case $(PERL) in\
>
> You probably want to put that in quotes, so $(PERL) expanding to two
> words won't cause a syntax error.
Thanks, R
I've had this change sitting around for a while...
* m4/regex.m4: Update the description of the configure-time option,
--without-included-regex, to state accurately what the defaults are,
and perhaps to give people an idea why using this option is risky.
Index: m4/regex.m4
Jim Meyering wrote:
> Although "case $(PERL)" often works,
> and looks ok because we know "case $shell_var" does not
> require quotes around $shell_var, here $(PERL) must be quoted,
> because it is expanded by make.
Yes, you're right. My mistake.
In gnulib and gettext, I therefore always put doub
Paul Eggert wrote:
> I installed the following patch, which should be harmless
> on valid nanosleep hosts; does it detect the bug on your platform?
Yes, it does. With this patch, "gmake check" passes all tests on AIX 4.3.2.
However, when built with "make", the program src/[ is not built. ("make"
Hi Paolo,
frexpl of 1.0L should return the exponent 1 and mantissa 0.5L. Glibc does
this. The substitute code in frexpl.c, however, returns the exponent 0 and
mantissa 1.0L, which IMO is wrong.
OK to fix this?
By the way, now that gnulib supports unit tests, how about moving the test
code at the
frexpl of 1.0L should return the exponent 1 and mantissa 0.5L. Glibc does
this. The substitute code in frexpl.c, however, returns the exponent 0 and
mantissa 1.0L, which IMO is wrong.
OK to fix this?
Ok for all. Don't even ask for approval of changes like the testsuite,
since you're much mo
On 2/18/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
Hmm, should we reduce the amount of gnulib changes in this period
I hope that sort of thing would not be necessary, otherwise gnulib
will have its development stalled by the release shedules of GNU
packages other than gnulib, presumably.
Jam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The GNU M4 Team is pleased to announce the beta release of GNU M4 1.4.8b.
GNU `m4' is an implementation of the traditional Unix macro processor. It
is mostly SVR4 compatible, although it has some extensions (for example,
handling more than 9 positiona
Hi,
A printf substitute should be able to print numbers in hexadecimal notation
(conversion 'a' or 'A'), and for this is needs to test whether a number is
NaN. The 'x == x' trick doesn't do it, because - as far as I know - this
can trap if x is a signalling NaN. So we need an isnan() function. But
Hi,
printf also needs to output long double numbers... so it needs an isnanl()
function as well. Like for isnan(), having it defined in libm (OSF/1,
Solaris) doesn't help.
2007-02-24 Bruno Haible <[EMAIL PROTECTED]>
* modules/isnanl-nolibm: New file.
* lib/isnanl.h: New file.
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2007-02-24 Bruno Haible <[EMAIL PROTECTED]>
>
> * modules/isnan-nolibm: New file.
> * lib/isnan.h: New file.
> * lib/isnan.c: New file.
> * m4/isnan.m4: New file.
Could/should this be merged into math_.h, so that there's no need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 2/24/2007 12:10 PM:
> But
> isnan() is available in libm on many systems (AIX, Cygwin, HP-UX, OSF/1,
> Solaris)
Correction - on cygwin, libm is a dummy library to merely pacify people
who insist on using -lm unnecessarily,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 2/24/2007 12:56 PM:
> According to Bruno Haible on 2/24/2007 12:10 PM:
>> But
>> isnan() is available in libm on many systems (AIX, Cygwin, HP-UX, OSF/1,
>> Solaris)
>
> Correction - on cygwin, libm is a dummy library to mer
On Sat, Feb 24, 2007 at 08:10:02PM +0100, Bruno Haible wrote:
> dnl On ARM, integer types are stored in little-endian byte order,
> dnl but floats are stored in big-endian word order.
> AC_EGREP_CPP([mixed_endianness], [
> #if defined arm || defined __arm || defined __
Ben Pfaff asked:
> > * lib/isnan.h: New file.
> Could/should this be merged into math_.h, so that there's no need
> for an additional #include "isnan.h"?
If many other modules want isnan() without libm, it would make sense.
If only *printf routines need it - and that's the current hypothesis
Daniel Jacobowitz wrote:
> That hasn't been the full story for a while. FPA (the obsolete,
> usually emulated floating point format) does this, but all modern
> systems use VFP word ordering, even if they have only software
> floating point.
Thanks for pointing this out. I'm changing the macro to
Eric Blake asked:
> For that matter, isnan() is specified to be a macro, not a function. On
> what platforms does the macro in the system truly rely on a libm
> function?
On AIX, OSF/1, HP-UX:
AIX 4.3.2: isnan() is a function, defined in libm
OSF/1 4.0d: isnan() is a function, defined in lib
I've just committed this:
[coreutils-6.8 needs this patch on FreeBSD]
Avoid conflicting types for 'unsetenv' on FreeBSD.
* lib/putenv.c (_unsetenv): Rename from "unsetenv", to avoid
conflicting with FreeBSD's (5.0 and 6.1) function declaration
in stdlib.h.
Index: l
Oops, this was code duplication, which is bad. I'm merging the two functions
into a single code.
2007-02-24 Bruno Haible <[EMAIL PROTECTED]>
* lib/isnan.c: Support the 'long double' case if USE_LONG_DOUBLE is
defined.
* lib/isnanl.c: Remove all code. Just include isnan.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 2/24/2007 7:08 PM:
> Cygwin: isnan() is a function, defined in cygwin.dll
No, on cygwin, isnan is a macro in that wraps the internal
functions __isnan{,lf}, and the isnan entry point in cygwin1.dll exists
only for ba
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff asked:
>> >* lib/isnan.h: New file.
>> Could/should this be merged into math_.h, so that there's no need
>> for an additional #include "isnan.h"?
>
> If many other modules want isnan() without libm, it would make sense.
I was under the impr
Eric Blake wrote:
> No, on cygwin, isnan is a macro in that wraps the internal
> functions __isnan{,lf}, and the isnan entry point in cygwin1.dll exists
> only for backwards compatibility for multi-year-old apps that were
> compiled against cygwin prior to the POSIX compliance bug being fixed of
>
Ben Pfaff wrote:
> I was under the impression that some platforms were missing isnan
> entirely, so that this was worth more than just "isnan() without
> libm". But I can't confidently name a system that lacks it.
The package I announced two days ago shows that most systems have isnan()
as a func
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> I was under the impression that some platforms were missing isnan
>> entirely, so that this was worth more than just "isnan() without
>> libm". But I can't confidently name a system that lacks it.
>
> The package I announced two days
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> pathname.h and dirname.h define macros with the same names, but
>> conflicting definitions. Should they be merged?
>
> Well, if you want my biased opinion, pathname should go. :-)
>
> The GNU Coding Standards sa
29 matches
Mail list logo
