does this mean that on memory allocation failure in getdate clisp will exit?
this is no good.
On 09/28/2010 08:13 AM, Sam Steingold wrote:
does this mean that on memory allocation failure in getdate clisp will
exit?
this is no good.
If you don't do anything about the default xalloc_die, then yes,
getdate() will exit on allocation failure. But if you provide an
alternate xalloc_die()
[adding bug-gnulib]
On 09/28/2010 06:36 AM, Justin Clift wrote:
This addresses a compilation failure issue reported last year on
OS X:
https://www.redhat.com/archives/libvir-list/2009-May/msg00166.html
which in turn mentions:
gcc -Wall -Wformat -Wmissing-prototypes -Wnested-externs -Wpoi
Bruno Haible wrote:
> Eric Blake wrote:
>> Because POSIX requires to provide WEXITSTATUS, among others,
>> but some systems don't do this by default. Therefore, the stdlib module
>> depends on sys_wait.
>
> This explains why 'stdlib' depends on 'sys_wait'.
>
> And why does 'regex' depend on 'std
On 09/29/2010 12:29 AM, Eric Blake wrote:
But the failed link mentions rpl_poll, not poll, which means this is
most likely a gnulib bug in the poll module. Rather than skipping this
test on just 32-bit MacOS in libvirt, I think the better thing to do is
address why gnulib is triggering a link fa
[replies can omit bug-gnulib]
On 09/28/2010 08:29 AM, Eric Blake wrote:
[adding bug-gnulib]
which in turn mentions:
gcc -Wall -Wformat -Wmissing-prototypes -Wnested-externs -Wpointer-
arith -Wextra -Wshadow -Wcast-align -Wwrite-strings
-Waggregate-return -Wstrict-prototypes -Winline -Wredunda
On 09/28/10 07:58, Jim Meyering wrote:
> However, if someone can come up with a patch that is relatively
> noninvasive, maybe... It's hard to say without seeing just how
> big a change would be required.
How about this patch? (I hope it's noninvasive enough. :-)
stdlib: don't depend on sys_wa
On 09/28/2010 10:28 AM, Paul Eggert wrote:
How about this patch? (I hope it's noninvasive enough. :-)
Nope, it breaks things on mingw, where we need the sys_wait replacement
to define macros like WEXITSTATUS in the first place before they can be
reused in the stdlib replacement. :(
+++
On 09/28/2010 10:30 AM, Eric Blake wrote:
On 09/28/2010 10:28 AM, Paul Eggert wrote:
How about this patch? (I hope it's noninvasive enough. :-)
Nope, it breaks things on mingw, where we need the sys_wait replacement
to define macros like WEXITSTATUS in the first place before they can be
reused
On 09/28/10 09:34, Eric Blake wrote:
> However, in thinking about it a bit more, a compromise would be to also
> modify tests/test-stdlib.c to check for the presence of whether the
> gnulib sys_wait module is in use, and skip validation of the
> status-related macros if it is not. Then, stdlib ca
On 09/28/2010 10:42 AM, Paul Eggert wrote:
On 09/28/10 09:34, Eric Blake wrote:
However, in thinking about it a bit more, a compromise would be to also
modify tests/test-stdlib.c to check for the presence of whether the
gnulib sys_wait module is in use, and skip validation of the
status-related
On 26 September 2010 12:37, Simon Josefsson wrote:
> Reuben Thomas writes:
>
>> On 21 September 2010 21:51, Simon Josefsson wrote:
>>> Thanks, applied. I didn't see a patch for ChangeLog in there though? I
>>> added it myself and pushed it separately.
>>
>> I used git format-patch, which seeme
Eric Blake wrote:
> Hmm - this would be the first time that one of our replacement headers
> #includes a non-replacement header
I agree that we shouldn't go this route. libunistring installs the gnulib-
created variants of stdint.h and stdbool.h in public locations (under different
names); I thin
Doing it as a "system" module looks good to me, too.
I have a qualm about the generic name "system"
for such a specialized module; perhaps "system-posix"
instead? But this is a minor quibble.
On 09/28/2010 01:33 PM, Bruno Haible wrote:
Eric Blake wrote:
Hmm - this would be the first time that one of our replacement headers
#includes a non-replacement header
I agree that we shouldn't go this route. libunistring installs the gnulib-
created variants of stdint.h and stdbool.h in publi
On 09/28/2010 01:40 PM, Paul Eggert wrote:
Doing it as a "system" module looks good to me, too.
I have a qualm about the generic name "system"
for such a specialized module; perhaps "system-posix"
instead? But this is a minor quibble.
The module name system accurately reflects that it is for
On 09/28/2010 10:18 AM, Eric Blake wrote:
gcc -Wall -Wformat -Wmissing-prototypes -Wnested-externs -Wpointer-
arith -Wextra -Wshadow -Wcast-align -Wwrite-strings
-Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls
-Wno-sign-compare -Wp,- D_FORTIFY_SOURCE=2 -fexceptions
-fasynchronou
On 09/28/10 12:44, Eric Blake wrote:
> The module name system accurately reflects that it is for the system(3)
> library call
But the "system" library call is standardized by ISO C99.
The proposed module implements the POSIX specification for "system",
which contains more requirements than the ISO
Eric Blake wrote:
> Also seems like a reasonable solution to me.
Thanks.
> > * lib/stdlib.in.h: Include only when the 'system' module
> > is present.
>
> It doesn't hurt to unconditionally include when WEXITSTATUS
> is undefined
Sure it hurts. On mingw, does not define WEXITSTATUS,
Paul Eggert wrote:
> perhaps "system-posix" instead?
Yes, indeed. The system() function is specified by ISO C and by POSIX. In
ISO C the return value is "an implementation-defined value", whereas in
POSIX the return value can be analyzed with WIFEXITED etc.
Here is an updated proposed patch.
Bru
Eric Blake wrote:
> modern style favors splitting
> replacement headers into separate modules from like-named functions
> (that is, we need a new module poll-h if you want a working poll.h
> [pollfd, nfds_t, and the various POLL macros] that can be used for
> GNULIB_POSIXCHECK conformance and w
After I wrote a unit test for the 'poll-h' module, I see it fails on glibc
platforms:
test-poll-h.c:28: error: ‘POLLRDNORM’ undeclared here (not in a function)
test-poll-h.c:28: error: ‘POLLRDBAND’ undeclared here (not in a function)
test-poll-h.c:28: error: ‘POLLWRNORM’ undeclared here (not in a
Eric Blake wrote:
> we need a new module poll-h if you want a working poll.h
> [pollfd, nfds_t, and the various POLL macros] that can be used for
> GNULIB_POSIXCHECK conformance
For using GNULIB_POSIXCHECK it is also necessary to create the .h file on
all platforms. Like what you did on 2009-12-
Another modernization of the 'poll' module is to use ANSI C instead of K&R C.
2010-09-28 Bruno Haible
poll: Assume ANSI C.
* lib/poll.c (poll): Use an ANSI C declaration.
--- lib/poll.c.orig Wed Sep 29 01:55:18 2010
+++ lib/poll.c Wed Sep 29 01:52:45 2010
@@ -315,10 +315
Hello
I am tring to build octave-3.3.52+ on MinGW (GCC-4.5.0) which uses the
gnulib.
In compliling oct-env.cc I have met the following error
libtool: compile: g++ -shared-libgcc -DHAVE_CONFIG_H -I.
-I../../../hg/octave-work/liboctave -I.. -I/c/Programs/gpnewlib/include
-I/c/Programs/OctaveLibs/
25 matches
Mail list logo
