On 06/19/2012 09:04 PM, Rich Felker wrote:
>> Replacement of duplocale, because of
>> checking whether duplocale(LC_GLOBAL_LOCALE) works... no
>
> POSIX does not specify any use of LC_GLOBAL_LOCALE except as an
> argument to uselocale. Is there a reason it's needed? Perhaps more
> importantly,
Some more updates..
On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
> Replacements of *printf, because of
> [...]
> checking whether printf survives out-of-memory conditions... no
This was caused by the pointer-arithmetic overflow bug I just fixed in
git. It should no longer fail,
On Tue, Jun 19, 2012 at 11:17:33PM +0200, Bruno Haible wrote:
> [...]
> The SIGSEGV occurs because d = 0x218b40 but the address ranges are these:
> 08048000-08049000 r-xp 08:05 26174991
> /data/bruno/tmp/testdir3/conftest
> 08049000-0804b000 rwxp 08:05 2
Daniel P. Berrange wrote:
> Attaching the stdio.h & sys/stat.h that I have
Thanks.
> > > CC fstat.lo
> > > ../../../gnulib/lib/fstat.c:27:0: warning: "stat" redefined [enabled by
> > > default]
> > > In file included from ./sys/stat.h:32:0,
> > > from ../../../gnulib/lib/f
Rich Felker wrote:
> stdio_ext.h okay?
OK, of course.
With these patches from your side, I am applying these changes to gnulib.
No need for "#ifdef __MUSL__" for now.
2012-06-19 Bruno Haible
stdioext: Add support for musl libc.
* m4/fbufmode.m4 (gl_FUNC_FBUFMODE): Test whet
Rich Felker wrote:
> Do you have a dynamic-linked musl or just static?
Dynamically linked:
$ readelf -d conftest
Dynamic section at offset 0xf3c contains 18 entries:
TagType Name/Value
0x0001 (NEEDED) Shared library: [libc.so]
0x000
On Tue, Jun 19, 2012 at 10:04:57PM +0200, Bruno Haible wrote:
> I can reduce the program and the compilation options:
>
> === conftest.c =
> #include
> #include
> int main()
> {
> int ret;
> int err;
> ret = printf ("%.500f", 1.0)
Rich Felker wrote:
> > but once I get
> >
> > configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2
> > -Wall conftest.c >&5
> > configure:8982: $? = 0
> > configure:8986: $? = 139
> > configure:9031: result: no
> >
> > So, apparently, under memory stress, musl's pr
On Tue, Jun 19, 2012 at 12:45:50PM +0200, Bruno Haible wrote:
> So, the exit code 1 must have come from the crash handler. Without this crash
> handler: 7x I get
>
> configure:8919: checking whether printf survives out-of-memory conditions
> configure:8979: /arch/x86-linux/inst-musl/bin/musl-g
On 06/19/2012 11:19 AM, Rich Felker wrote:
>> POSIX is at liberty to define semantics that are not guaranteed by
>> C99/C11, and dlsym() is one of those situations where POSIX has indeed
>> required more from the compiler (including that function pointers can be
>> cast to void* and back again wit
On Tue, Jun 19, 2012 at 06:11:35AM -0600, Eric Blake wrote:
> On 06/18/2012 09:30 PM, Rich Felker wrote:
>
> >>
> >> And that's where I disagree - the POSIX folks _specifically_ recommend
> >> the closeout approach of an atexit() handler:
> >
> > Yes, they also recommend invoking extremely seriou
On Tue, Jun 19, 2012 at 01:46:40PM +0200, Bruno Haible wrote:
> Hi Rich,
>
> The patches that you've committed at
>
> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=deb90c79e5c498fbb48de1423df034447f330e38
>
> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e
> Date: Tue, 17 Jan 2012 22:04:38 +0200
> From: Eli Zaretskii
> CC: bug-gnulib@gnu.org
>
> > From: Bruno Haible
> > Bcc: br...@haible.de
> > Date: Tue, 17 Jan 2012 20:07:11 +0100
> >
> > Thanks, I'll look into integrating it.
>
> Thanks, looking forward to it.
>
> > Do you also have a set of
> From: Akim Demaille
> Date: Tue, 19 Jun 2012 14:15:19 +0200
> Cc: Eric Blake ,
> bug-gnulib@gnu.org
>
> > Maybe I'm looking at the wrong source file in gnulib. but I see these
> > at the beginning of canonicalize_filename_mode:
> >
> > if (name == NULL)
> >{
> > errno = EINVAL;
> >
On 06/18/2012 08:30 PM, Rich Felker wrote:
> after a
> successful flush, I consider it the operating system's data loss, not
> the application's, if the data fails to end up on permanent storage.
Many operating systems behave that way, alas. This is for
performance reasons. NFS is a classic exam
On 06/19/2012 05:51 AM, John Spencer wrote:
> #ifdef SYS_USES_LD80
> x = get_valid_ld80_or_zero(x);
> #endif
>
> OSLT. why should i care ? go figure it out yourself.
As I understand it, it was your assertion that code like
GNU od's could be written portably, using standard C.
I was merely trying
Eric Blake wrote:
> On 06/19/2012 06:51 AM, John Spencer wrote:
>> *sigh*.
>> talking to you guys is like talking to a wall.
>
> Please don't swear. This is a publicly archived list, and you are
> coming across rather offensive. A positive attitude is more likely to
> foster cooperation than bera
On 06/19/2012 06:51 AM, John Spencer wrote:
> *sigh*.
> talking to you guys is like talking to a wall.
Please don't swear. This is a publicly archived list, and you are
coming across rather offensive. A positive attitude is more likely to
foster cooperation than berating others.
>> There's no f
*sigh*.
talking to you guys is like talking to a wall.
seriously, with your attitude you will render GNU a complete joke in
less than a decade, even moreso than it is already.
unfortunately that will also affect the FSF.
On 06/19/2012 04:37 AM, Paul Eggert wrote:
On 06/18/2012 06:27 PM, John S
Le 18 juin 2012 à 18:31, Eli Zaretskii a écrit :
>> No, canonicalize_filename_mode is GPL because it calls xalloc() and dies
>> rather than return NULL.
>
> Maybe I'm looking at the wrong source file in gnulib. but I see these
> at the beginning of canonicalize_filename_mode:
>
> if (name == N
On 06/18/2012 09:30 PM, Rich Felker wrote:
>>
>> And that's where I disagree - the POSIX folks _specifically_ recommend
>> the closeout approach of an atexit() handler:
>
> Yes, they also recommend invoking extremely serious UB (aliasing
> violation, which GCC _will_ miscompile) when using dlsym
Hi Eric,
> waitpid() distinguishes between normal exits > 128 and a
> signal exit, and all existing shells are good about only reporting core
> dumps or other signal exits when waitpid() says the child exits via
> signal. It's just the ambiguity that results when dealing with $? after
> the fact,
Hi Rich,
The patches that you've committed at
http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=deb90c79e5c498fbb48de1423df034447f330e38
http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e15171b8d8e80e8b5bcf4e95b1709697858f545a
go a long way at implementing the su
On 06/19/2012 04:11 AM, Bruno Haible wrote:
> Exit codes are limited to be < 128. Values between 128 and 255 are reported
> as core dumps by the invoking shell.
Not true. waitpid() distinguishes between normal exits > 128 and a
signal exit, and all existing shells are good about only reporting co
Bruno Haible wrote:
...
>> My thought in having musl skip the test is to maximize performance of
>> fdopen, assuming you might be using it in a situation like on a newly
>> accept()ed network connection where every syscall counts (think
>> multi-threaded httpd). For read-only fdopen, no syscalls ar
Rich Felker wrote:
> > >> Replacement of fdopen, because of
> > >> checking whether fdopen sets errno... no
> > >
> > > There was one bug here (failure to set errno when mode string was
> > > invalid) but I don't think that's the case gnulib was testing for. It
> > > seems gnulib wants an error
Rich Felker wrote:
> > Replacements of *printf, because of
> > [...]
> > checking whether printf survives out-of-memory conditions... no
>
> No idea. Copying out the test and running it directly, it passes just
> fine for me. Maybe gnulib has already replaced printf with its own
> malloc-using v
Exit codes are limited to be < 128. Values between 128 and 255 are reported
as core dumps by the invoking shell. To avoid such misinterpretations,
this fix. The problem was introduced on 2011-07-07.
2012-06-19 Bruno Haible
getopt-gnu: Fix exit code overflow in autoconf test.
*
Rich Felker wrote:
> > > 3. The test for "POSIX compatible" getopt does not actually test for
> > > POSIX compatibility, but for GNU semantics which are contrary to
> > > POSIX. This is purely an issue of a misnamed test; if gnulib wants to
> > > provide a replacement getopt with GNU semantics, tha
29 matches
Mail list logo
