Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Jim Meyering wrote:
>> Bad timing. I was about to make a test release.
>> If anyone else has access to a Solaris 10 system (x86 or otherwise),
>> with Sun C, would you please try the latest snapshot?
>>
>> http://meyering.net/cu/
>
> FYI if you feel
Hi,
In the test module descriptions, we still have a workaround against a
problem with automake 1.9.x versions. This is fixed in automake 1.10:
$(EXEEXT) is automatically appended to filenames of TESTS
that have been declared as programs in the same Makefile.
This is mostly useful whe
This module is also for the 'a' and 'A' conversion of printf: Splitting a
'double' into mantissa and exponent, without requiring libm.
This module assumes that the radix of floating-point numbers is 2. A safe
assumption, I hope, 18 years after IEEE 754.
2007-02-25 Bruno Haible <[EMAIL PROTECTED
Similarly to 'printf-frexp', here is the corresponding module for
'long double'.
2007-02-25 Bruno Haible <[EMAIL PROTECTED]>
* modules/printf-frexpl: New file.
* lib/printf-frexpl.h: New file.
* lib/printf-frexpl.c: New file.
* m4/printf-frexpl.m4: New file.
===
This patch changes compat.in to compat.h. It's no longer installable
standalone, although if someone is interested in making it standalone
again later it wouldn't be hard (via the same @@ substitution
technique that some other headers in gnulib use). In the process, the
static inline check went a
Daniel Jacobowitz wrote:
> Paolo's updates added a check for runetype.h
> in order to make Mac OS/X's work properly. Perhaps gnulib's
> substitute wchar.h ought to handle that?
For which version of Mac OS X was this? MacOS X 10.3 has a working .
MacOS X 10.2 has no wchar.h at all. When gnulib in
On Sun, Feb 25, 2007 at 03:56:46PM +0100, Bruno Haible wrote:
> Daniel Jacobowitz wrote:
> > Paolo's updates added a check for runetype.h
> > in order to make Mac OS/X's work properly. Perhaps gnulib's
> > substitute wchar.h ought to handle that?
>
> For which version of Mac OS X was this? MacOS
Paul Eggert wrote:
> > Well, if you want my biased opinion, pathname should go. :-)
> >
> > The GNU Coding Standards say that one shouldn't use the word
> > "pathname" to describe file names.
If that is your only argument, I can rename this module to 'filename'.
Ben Pfaff wrote:
> Here is my att
Hi! Do we need to put link-warning.h in build-aux/? Since it is a C
header file, having it in the lib/ directory seems cleaner to me.
(I noticed this because my build-aux directory is '.', so all gnulib
scripts end up in my top-level project directory, which is fine because
there is where the ot
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> Here is my attempt at a minimally invasive resolution of the
>> differences
>
> This is backwards. You introduce a dependency from a simple module to a
> complicated module. The purpose of 'filename' (ex-'pathname') is to do
> the most
I've checked in this change:
* build-aux/announce-gen: When complaining about excess arguments,
list them.
Index: build-aux/announce-gen
===
RCS file: /sources/gnulib/gnulib/build-aux/announce-gen,v
retrieving revisio
Bruno Haible <[EMAIL PROTECTED]> writes:
> This module assumes that the radix of floating-point numbers is 2. A safe
> assumption, I hope, 18 years after IEEE 754.
IBM mainframes use radix 16. This is not likely to change so long as
there are IBM mainframes (which will be quite some time). Mode
Hi Simon,
> Hi! Do we need to put link-warning.h in build-aux/? Since it is a C
> header file, having it in the lib/ directory seems cleaner to me.
The file is not included by the C compiler. It's used by some Makefile rules
that don't involve a compiler. Therefore build-aux/ is the natural pla
Bruno Haible <[EMAIL PROTECTED]> writes:
> Solaris 10: isnan() is a function, defined in libc
Not that this affects the conclusion, but the Solaris isnan is present
only for legacy apps. On Solaris 10 isnan is a macro that expands to
__builtin_isnan, and __builtin_isnan is done inline.
The isn
Ben Pfaff wrote:
> now I can use both headers at once, which is what I wanted.
huh? Nothing has been committed to that effect. I only renamed pathname.h
to filename.h, since that was Paul's objection.
To get rid of the macro redefinition warnings, you still need to negotiate
with Jim and me.
Bru
Daniel Jacobowitz wrote:
> On Sun, Feb 25, 2007 at 03:56:46PM +0100, Bruno Haible wrote:
>> Daniel Jacobowitz wrote:
>>> Paolo's updates added a check for runetype.h
>>> in order to make Mac OS/X's work properly. Perhaps gnulib's
>>> substitute wchar.h ought to handle that?
>> For which version o
Paul Eggert wrote:
> IBM mainframes use radix 16. This is not likely to change so long as
> there are IBM mainframes (which will be quite some time). Modern IBM
> mainframes support radix 2 as an option, but I suspect radix 16 is
> still the normal default
Oh well. I'm adding a comment about it.
Paul Eggert wrote:
> > Solaris 10: isnan() is a function, defined in libc
>
> Not that this affects the conclusion, but the Solaris isnan is present
> only for legacy apps. On Solaris 10 isnan is a macro that expands to
> __builtin_isnan, and __builtin_isnan is done inline.
Huh? On a Solaris 10
Hi Jim,
Ben Pfaff noticed that there two versions of xreadlink in gnulib and gettext
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gnulib/lib/xreadlink.c?content-type=text%2Fplain&rev=1.23&root=gnulib
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/xreadlink.c?conten
Hi gnulibers, Eric,
On 23 Feb 2007, at 09:05, Eric Blake wrote:
Eric Blake byu.net> writes:
Gnulib just enhanced to guarantee GNU properties,
obsoleting
several
minor headers in the process.
Another gnulib update during my 2-week vacation got rid of exit.h.
At this
point, because of
Hello Ben,
> I've finished my first stab at a "relocatable" module for gnulib.
Thanks a lot for getting this rolling after so many years of stagnation
on my side!
> What I've done is essentially to assemble the relocatable stuff
> into a gnulib module, and then test it a little bit. The first
>
Ralf Wildenhues wrote:
> > The wrapper
> > +sets the environment variable that controls shared library searching
> > +(usually @env{LD_LIBRARY_PATH}) and then invokes the real executable.
>
> The problem is here that this is not always possible. There are two
> failure scenarios (at least):
>
>
Bruno Haible <[EMAIL PROTECTED]> wrote:
> What can we do in gnulib?
>
> (a) Have 2 xreadlink like functions. Since the one without prior stat is more
> natural, I would propose to rename the coreutils one, with the 'size'
> argument, to 'xreadlink_after_stat'.
>
> Or
>
> (b) Merge the two f
Hi Daniel,
I found a number of misuses of casts in the subversion sources.
Attached are two difference files: one vs. the libsnv source
on subversion, the other against my variation in autogen.
The primary difference (after application of the first patch)
is that snprintfv.m4 and compat.h are wi
"Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> For this reason, and for the difficulty of reboot-strapping old releases
> of gnulib using projects, I find the anti-release model of gnulib
> somewhat
> depressing. It would be nice for gnulib to make occasional feature
> freezes,
> or release branch
This fixes a wrong estimate of a buffer size, when a format directive
'a' or 'A' is used.
Fortunately this affects only platforms without snprintf or _snprintf
functions, i.e. systems such as OSF/1 4.0 or Solaris < 2.6.
2007-02-25 Bruno Haible <[EMAIL PROTECTED]>
* lib/vasnprintf.c (V
Bruce Korb wrote:
> @@ -193,7 +197,7 @@ call_argtype_function (struct printf_inf
>
>else
> {
> - pinfo->spec = *(unsigned char *) pinfo->format;
> + pinfo->spec = (unsigned)*(pinfo->format);
>pinfo->extra = spec->user;
>pinfo->type = spec->type;
The cast is a no
Bruno Haible wrote:
> The cast is a no-op anyway. Since pinfo->format is of type 'const char *'
> and pinfo->spec is of type 'char', both variants are equivalent to
I guess it is a preference issue: I like to remember as few
special cases as absolutely possible. There's too much to
remember as i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruce Korb on 2/25/2007 10:45 AM:
> I would sure hope that fixing this winds up as easy as adding
> "wchar-h.m4" module and in my code:
>
> #include "config.h"
> #include WCHAR_H_FILE
In fact, it is a matter of using the 'wchar' modu
Bruce Korb writes:
>
> I guess it is a preference issue: I like to remember as few
> special cases as absolutely possible. There's too much to
> remember as it is. "Never dereference a cast pointer" is simple.
Yes, it is. Unfortunately, it's also wrong. If you have a pointer to
char but need
Larry Jones wrote:
> Bruce Korb writes:
>> I guess it is a preference issue: I like to remember as few
>> special cases as absolutely possible. There's too much to
>> remember as it is. "Never dereference a cast pointer" is simple.
>
> Yes, it is. Unfortunately, it's also wrong. If you have a
Hi Jim,
Thanks for the swift response.
On 25 Feb 2007, at 12:48, Jim Meyering wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
For this reason, and for the difficulty of reboot-strapping old
releases
of gnulib using projects, I find the anti-release model of gnulib
somewhat
depressing. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gary V. Vaughan on 2/25/2007 2:22 PM:
>
> My problem is that I don't know how to pick a snapshot date that
> will include recent fixes to modules M4 cares about, but not
> destabilizing changes that occured in the same timeframe.
>
> I'm
Eric Blake <[EMAIL PROTECTED]> wrote:
...
> Eventually, when the move to git is complete, doing this will be easy -
> you just make a branch in your local git copy of gnulib, and base your m4
> release off of that branch.
>
> But so far, it has not been too much of an issue - I have been actively
>
On Sun, Feb 25, 2007 at 12:46:05PM -0800, Bruce Korb wrote:
> Hi Daniel,
>
> I found a number of misuses of casts in the subversion sources.
> Attached are two difference files: one vs. the libsnv source
> on subversion, the other against my variation in autogen.
> The primary difference (after
Hi Jim, Eric,
On 25 Feb 2007, at 15:45, Jim Meyering wrote:
Eric Blake <[EMAIL PROTECTED]> wrote:
...
Eventually, when the move to git is complete, doing this will be
easy -
you just make a branch in your local git copy of gnulib, and base
your m4
release off of that branch.
But so far, it
Eric Blake wrote:
> > and, perhaps, on whichever OS/X it is that needs the "runetype.h"
>
> > The bottom line is that there really is some flavor of OS/X that
> > has this pre-include of "runetype.h" requirement out there somewhere.
>
> Is this patch okay to apply so that the existing wchar modul
Eric Blake wrote:
> Eventually, when the move to git is complete, doing this will be easy -
> you just make a branch in your local git copy of gnulib, and base your m4
> release off of that branch.
git will certainly help in doing so.
But what Gary also wants is the knowledge, that we 4 (you, Pau
Hi Bruno,
On 25 Feb 2007, at 18:25, Bruno Haible wrote:
Eric Blake wrote:
Eventually, when the move to git is complete, doing this will be
easy -
you just make a branch in your local git copy of gnulib, and base
your m4
release off of that branch.
git will certainly help in doing so.
But
* Daniel Jacobowitz wrote on Mon, Feb 26, 2007 at 01:29:53AM CET:
>
> That's from standalone libsnprintfv DLL support, which we're
> obsoleting as we fold it into gnulib. It doesn't work quite right
> anyway, since none of the snprintfv interface functions are marked as
> dllexport. Marking some
* Bruno Haible wrote on Sun, Feb 25, 2007 at 09:30:59PM CET:
> Ralf Wildenhues wrote:
> >
> > - A library was hardcoded with an absolute path, and you cannot override
> > it at all (e.g., DT_NEEDED contains /path/to/libfoo.so, which Libtool
> > branch-1-5 does on OpenBSD; also I think OpenSer
* Bruno Haible wrote on Sun, Feb 25, 2007 at 09:23:09PM CET:
>
> > * It looks like Automake support is wanted for
> > automatically defining foo_CFLAGS and foo_LDFLAGS. Any
> > suggestion about what mechanism should be used to
> > trigger this? e.g. somethin
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Bruno Haible wrote on Sun, Feb 25, 2007 at 09:23:09PM CET:
>>
>> > * It looks like Automake support is wanted for
>> > automatically defining foo_CFLAGS and foo_LDFLAGS. Any
>> > suggestion about what mechanism should be
* Ben Pfaff wrote on Mon, Feb 26, 2007 at 05:41:15AM CET:
>
> The issue is foo_CFLAGS and foo_LDFLAGS need to refer back to the
> directory in which foo is installed. Thus, if foo is in
> bin_PROGRAMS then the following is correct:
>
> foo_CFLAGS = -DINSTALLDIR=\"$(bindir)\"
> if REL
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Ben Pfaff wrote on Mon, Feb 26, 2007 at 05:41:15AM CET:
>>
>> The issue is foo_CFLAGS and foo_LDFLAGS need to refer back to the
>> directory in which foo is installed. Thus, if foo is in
>> bin_PROGRAMS then the following is correct:
>>
>> f
Bruce Korb writes:
>
> Larry Jones wrote:
> >
> > If you have a pointer to
> > char but need to treat the data it points to as unsigned char, you have
> > to cast the pointer and dereference it to get the correct value on ones
> > complement systems -- dereferencing and then casting doesn't work
Bruno Haible <[EMAIL PROTECTED]> writes:
> (Are such mainframes porting targets for GNU software?
Yes. I've gotten bug reports from users of such mainframes,
relatively recently.
> Do they lack the C99 printf 'a' and 'A' conversion?)
It depends on the compiler and version. For example, SAS/C
Bruno Haible <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> > Solaris 10: isnan() is a function, defined in libc
>>
>> Not that this affects the conclusion, but the Solaris isnan is present
>> only for legacy apps. On Solaris 10 isnan is a macro that expands to
>> __builtin_isnan, and __bu
[EMAIL PROTECTED] (Larry Jones) writes:
> Yes, it is. Unfortunately, it's also wrong. If you have a pointer to
> char but need to treat the data it points to as unsigned char, you have
> to cast the pointer and dereference it to get the correct value on ones
> complement systems -- dereferencing
I installed this:
2007-02-25 Paul Eggert <[EMAIL PROTECTED]>
* README: Document signed integer overflow situation more
accurately.
--- README 29 Nov 2006 00:41:00 - 1.18
+++ README 26 Feb 2007 07:43:39 -
@@ -141,10 +141,30 @@ than 'long'. POSIX 1003.1-20
50 matches
Mail list logo
