sa_family_t

Mingw and IRIX does not seem to have sa_family_t. Does anyone know of a system where 'unsigned short' is not the appropriate type for sa_family_t? It has to be the same type as the sin_family field in struct sockaddr_in, or the sa_family field in struct sockaddr. Those structs typically exists o

SIZE_MAX

I got a report about SIZE_MAX problems: In file included from ../gnutls_int.h:29, from opencdk.h:30, from kbnode.c:31: ../config.h:357:1: warning: "SIZE_MAX" redefined In file included from ./../gl/stdlib.h:52, from kbnode.c:28: ./../gl/stdint.h:4

Re: Static inlining in the gl-list module

Bruno Haible writes: > 2 questions: > > - What is this warning actually warning about? What can go wrong if an > 'extern inline' > function uses a 'static inline' function that was defined previously? > > - I see the source code of pdf-list.h in > >

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

On Tuesday 19 May 2009 07:08:37 Bruno Haible wrote: > Mike Frysinger wrote: > > we're of course trying to > > figure out who is blocking the signal in the first place, but it isnt > > exactly a trivial affair when it crops up on some users systems and they > > cant always reproduce it. > > Yes, I k

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

Mike Frysinger wrote: > we're of course trying to > figure out who is blocking the signal in the first place, but it isnt exactly > a trivial affair when it crops up on some users systems and they cant always > reproduce it. Yes, I know that on Gentoo systems, many reported bugs can never be cl

Re: Static inlining in the gl-list module

Hello, David Vazquez wrote: > I am developer in the GNUPDF project development, where we are using > some gnulib modules. Recently, we have some troubles with static > inlining from the gl-list module, with gcc 4.3.2 version. They are > warnings like: > >gcc -DHAVE_CONFIG_H -I. -I../lib -I./b

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

On Tuesday 19 May 2009 06:22:05 Bruno Haible wrote: > Mike Frysinger wrote: > > Some systems might have SIGALRM blocked when running configure. If that > > is the case, the nanosleep() test will sleep for practically ever as the > > signal generated by alarm() is never delivered. As such, we shou

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

Mike Frysinger wrote: > Some systems might have SIGALRM blocked when running configure. If that > is the case, the nanosleep() test will sleep for practically ever as the > signal generated by alarm() is never delivered. As such, we should make > sure to unblock SIGALRM before running any tests.