Bruno Haible <[EMAIL PROTECTED]> writes:
> - autoconf can probably mark the AC_TYPE_LONG_DOUBLE macro as "obsolescent".
Thanks for the suggestion. I installed this into Autoconf:
2007-04-06 Paul Eggert <[EMAIL PROTECTED]>
* doc/autoconf.texi (Particular Types): AC_C_LONG_DOUBLE is
Here's a proposed patch to 'signbit' to have it use 'copysign' if
available.
Normally the 'signbit' implementation relies on undefined behavior, as
it accesses the "wrong" member of a union; but when copysign is
available the implementation can use copysign's well-defined behavior
instead. This i
[EMAIL PROTECTED] (Karl Berry) writes:
> Personally, since we're already listing some of the programs from
> coreutils, I don't really see a lot of practical issues arising from
> adding any others. Or am I missing something?
We can't assume that coreutils is installed. Lots of people build
wit
So I gather that `fold', `cut', and `paste' stand no chance of
ending up listed in make-stds.texi?
I've never approached rms about adding to the command lists, but it
seems reasonable to suppose that he would want a justification for each
one, ie, why the job can't be reasonably accomplish
This makes use of the signbit macro in the vasnprintf module, as proposed by
Paul.
2007-04-06 Bruno Haible <[EMAIL PROTECTED]>
* lib/vasnprintf.c: Include . Don't include float+.h.
(VASNPRINTF): Use signbit for faster determination whether to print a
minus sign.
Paul mentioned copysign and signbit as possible new gnulib modules. Here
is the 'signbit' module.
2007-04-06 Bruno Haible <[EMAIL PROTECTED]>
* modules/signbit: New file.
* lib/signbitf.c: New file.
* lib/signbitd.c: New file.
* lib/signbitl.c: New file.
ISO C99 wants also some functions that operate on 'float', not only on
'double' or 'long double'. I'm not sure whether a conversion of a signalling
NaN(f) to a 'double' value will crash the program or not, so better be careful:
I'm adding a module 'isnanf' that test a 'float' for NaN.
2007-04-06
This is needed as well: When the gettext module is present, the test
programs indirectly rely on the gettext() function, therefore they must
use @[EMAIL PROTECTED] But when the gettext module is not present, they must not
link with -lintl - hence LIBINTL must be AC_SUBSTed with an empty value.
20
On Wed, Apr 04, 2007 at 10:45:44PM -0500, Albert Chin wrote:
> On Wed, Apr 04, 2007 at 09:14:12PM -0600, Eric Blake wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > According to Albert Chin on 4/4/2007 8:59 PM:
> > >
> > > Unfortunately, "#include_next " doesn't include
> > >
For a long time, noone has reported builds from OSes like "Stardent Vistra"
or "Ultrix". All proprietary compilers I have access to (including msvc)
also pass the gt_TYPE_LONGDOUBLE test.
This means that
- gnulib can assume that the type 'long double' exists (but not the
corresponding libra
Fred J. Tydeman writes:
>
> C99+TC1+TC2: 7.19.6.1 The fprintf function
> Paragraph 6, discussion on the '0' flag: ... leading zeros ...
> are used to pad to the field width rather than performing space
> padding, except when converting an infinity or NaN.
Base C99 says the same thing, it wasn't
PS: Likewise for .
*** lib/inttypes_.h 21 Feb 2007 00:02:37 - 1.8
--- lib/inttypes_.h 6 Apr 2007 12:51:45 -
***
*** 21,27
which in turn includes this file. */
#if ! defined INTTYPES_H || defined _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
# if @HAVE_INTTYPE
Eric Blake wrote:
> > "-nodtk" has already been found to be the
> > preferred workaround against this system's broken .
>
> But that was before the introduction of the wchar and absolute-header
> modules, so perhaps in fixing absolute-header to use #include_next when
> possible we can ALSO fix thi
Albert Chin wrote:
> If I change:
> #include "///usr/include.dtk/stdio.h"
> to:
> #include_next
> then it works as expected (./stdio.h, /usr/include.dtk/stdio.h,
> /usr/include/stdio.h).
>
> If I #include_next "///usr/include.dtk/stdio.h", it does not.
Thanks for these tests.
Furthermore th
Paul Eggert asked:
> Does the Tru64 compiler define __GNUC__, or some other similar symbol?
It defines __DECC. [1] is a handy resource for this.
Both "cc" and "cc -nodtk" define __DECC to the same value, and both support
#include_next.
Bruno
[1] http://predef.sourceforge.net/
15 matches
Mail list logo
