I wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Paul Eggert wrote:
>>> I suspect it may not be the last word, with all
>>> these screwy compilers to test).
>>
>> Indeed, IRIX 6.5 cc gives "warning: signed bitfield of length 1".
>>
>> Changing the verify_type__ macro like this makes it wor
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> I suspect it may not be the last word, with all
>> these screwy compilers to test).
>
> Indeed, IRIX 6.5 cc gives "warning: signed bitfield of length 1".
>
> Changing the verify_type__ macro like this makes it work without warning
Bruno Haible <[EMAIL PROTECTED]> writes:
> Changing the verify_type__ macro like this makes it work without warning.
>
> # define verify_type__(R) \
> struct { int verify_error_if_negative_size__ : (R) ? 2 : -1; }
Thanks. I installed that.
I'm thinking of talking about verify.h in my progra
James Gallagher <[EMAIL PROTECTED]> writes:
> Please let me know when the fix is in CVS or if you'd like me to
> submit a patch.
OK, I've installed this into both gnulib and coreutils. The long list is
awkward
2005-09-23 Paul Eggert <[EMAIL PROTECTED]>
* regex.m4 (gl_REGEX): If r
Paul Eggert <[EMAIL PROTECTED]> wrote:
>> Probably due to differing prototypes.
>> Do you think it's worth adding a cast or two?
>
> How about if we instead detect the implementation bug and use our own
> fnmatch? I installed this -- does it fix the problem?
Much better. Shame on me for suggesti
Paul Eggert wrote:
> I suspect it may not be the last word, with all
> these screwy compilers to test).
Indeed, IRIX 6.5 cc gives "warning: signed bitfield of length 1".
Changing the verify_type__ macro like this makes it work without warning.
# define verify_type__(R) \
struct { int ver
Jim Meyering <[EMAIL PROTECTED]> writes:
> On an x86_64 linux 2.6.9 system with
> CC=/usr/local/sys/sunstudio/sunstudio10u1/bin/cc
>
> HOST=abajo.math.utah.edu
> HOSTTYPE=x86_64-linux
>
> I see this build failure:
>
> /usr/local/sys/sunstudio/sunstudio10u1/bin/cc -DHAVE_CONFIG_H
> -DLIBDIR=\"
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> This is redundant. The module dependency from 'getaddrinfo' to 'socklen'
>> already implies that gl_SOCKLEN_T must be invoked from configure.ac,
>> directly or indirectly. No need to repeat the module dependenci
Bruno Haible <[EMAIL PROTECTED]> writes:
> This is redundant. The module dependency from 'getaddrinfo' to 'socklen'
> already implies that gl_SOCKLEN_T must be invoked from configure.ac,
> directly or indirectly. No need to repeat the module dependencies in the
> *.m4 files.
Right you are. I und
I installed the following into both gnulib and coreutils, to port the
utimens module to Solaris 10, which has yet another primitive for
setting file time stamps (and yet another primitive that can't do it
to full resolution! When will these guys learn?).
2005-09-23 Paul Eggert <[EMAIL PROTECTED]
Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> How about the following patch instead? I installed it in gnulib and
> coreutils (though I suspect it may not be the last word, with all
> these screwy compilers to test).
>
> 2005-09-23 Paul Eggert <[EMAIL PROTECTED]>
>
> * verify.h (GL_CONC
Bruno Haible <[EMAIL PROTECTED]> writes:
> If we can get away without this restriction, we should.
I agree, but like Jim I'd rather avoid the Autoconf test if we can.
How about the following patch instead? I installed it in gnulib and
coreutils (though I suspect it may not be the last word, wit
Jim Meyering wrote:
> # Prerequisites of lib/getaddrinfo.h and lib/getaddrinfo.c.
> AC_DEFUN([gl_PREREQ_GETADDRINFO], [
> + AC_REQUIRE([gl_SOCKLEN_T])
>AC_REQUIRE([gl_C_RESTRICT])
>AC_REQUIRE([gl_SOCKET_FAMILIES])
This is redundant. The module dependency from 'getaddrinfo' to 'socklen'
Yes, that does fix the problem.
Please let me know when the fix is in CVS or if you'd like me to submit
a patch.
Thanks.
On Sep 22, 2005, at 11:16 PM, Paul Eggert wrote:
James Gallagher <[EMAIL PROTECTED]> writes:
g++ -I./GNU -g -O2 -o getdap getdap.o -Wl,-bind_at_load
./.libs/libdap.a -L
I've just discovered/fixed a build problem with the getaddrinfo module.
It didn't depend on the socklen module (for the declaration of socklen_t).
So I've merged these changes from coreutils:
2005-09-23 Jim Meyering <[EMAIL PROTECTED]>
* modules/getaddrinfo (Depends-on): Add socklen.
2
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> The point of using a bitfield width was to ensure that improper
>> usage (non-constant argument) like this provokes an error even with
>> non-gcc compilers:
>>
>> void foo (int n) { verify (n); }
>>
>> With the preceding, array-dim
Jim Meyering wrote:
> The point of using a bitfield width was to ensure that improper
> usage (non-constant argument) like this provokes an error even with
> non-gcc compilers:
>
> void foo (int n) { verify (n); }
>
> With the preceding, array-dimension-based approach,
> the erroneous usage would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 9/22/2005 11:14 PM:
> Thanks for reporting that. Aside from the missing
> that you mentioned, I noticed a few other glitches.
>
> I installed the following fix into coreutils; does it fix things for
> you? If so, it shou
Hello,
On Fri, Sep 23, 2005 at 02:37:06PM +0200, Bruno Haible wrote:
> Stepan Kasal wrote:
> > But in the basic case, when only the implementation is fixed and no
> > header is needed, I see no advantage in adding a redundant call to
> > AC_LIBSOURCES.
>
> The advantage is simplicity and consiste
Stepan Kasal wrote:
> But in the basic case, when only the implementation is fixed and no
> header is needed, I see no advantage in adding a redundant call to
> AC_LIBSOURCES.
The advantage is simplicity and consistency.
In an ideal world, all source files are listed in Makefile.am. Very simple,
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> The first step is to add a new module "verify", which defines macros
>> verify(EXPR) and verify_expr(EXPR) that act like assert(EXPR) except
>> they check EXPR at compile-time, not at run-time. verify(EXPR) is for
>> declaration conte
Hello,
I propose the patch attached below; an explanation follows:
I think that when AC_LIBOBJ and friends was designed, the idea was
to use
some testing
if foo_is_broken; then
AC_LIBOBJ([foo])
fi
The AC_LISOURCE/AC_LIBSOURCES macros were also made visible
Hello again,
On Fri, Sep 23, 2005 at 10:33:21AM +0200, Stepan Kasal wrote:
> > > I'm afraid we need a design document for the solution.
> Simon, perhaps you could volunteer.
... or you can just wait. I think I have something in mind now,
and hopefully I'll write it down sometimes next week.
Ha
Paul Eggert wrote:
> The first step is to add a new module "verify", which defines macros
> verify(EXPR) and verify_expr(EXPR) that act like assert(EXPR) except
> they check EXPR at compile-time, not at run-time. verify(EXPR) is for
> declaration contexts, and verify_expr is for expression context
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Would it be possible to create those three POSIX header files if they
>> don't exist on the system, and if winsock2.h do exist? The created
>> files would simply #include .
>
> Yes, that's the way I would go.
It seems doing tha
Hello,
> > I'm afraid we need a design document for the solution. Then we can
> > implement it. Have I missed it, or it is yet to be written?
>
> No, I don't think you've missed it; that work still needs to be done.
but I'm not able to do it. Simon, perhaps you could volunteer.
Could you ple
26 matches
Mail list logo
