On 12/22/2010 03:32 PM, Bruno Haible wrote:
> For example, if save_cwd called
> currdir_fd = open (".");
> then on a platform that supports fchdir() natively [not gnulib's
> emulation], a failure to do fchdir (currdir_fd) is of type (a).
> It can only occur if some other part of the program did
Hi Bruno
Yes it does look similar to HP-UX, OSF/1, so wherever I could I copied that
code.
$ ./stdioext-flags
#define _IOERR 0x40
#define _IOREAD 0x80
#define _IOWRT 0x4
#define _IORW 0x100
#define _IORW 0x100
Very nice.
Downloaded, unpacked, modified gllib/stdio-impl.h as
Hi Bruno
I believe I did this earlier and sent you some patches, back in early October
this year and from my company email account (schm...@hp.com), in connection
with getting ACL support to work for HP-NonStop.
Anyway, here it goes, it is not finished, but I'm not sure how to go forward.
'mak
On 12/22/10 14:07, Bruno Haible wrote:
> Ping? No one wants to solve this? It's a critical issue for libposix.
I don't mind breaking the link, but I've been defocused by focusing
on too many things at once. I'm leaving for Christmas in a few hours.
I'll try to get to it later next week.
Thank yo
Hi,
I've released a new stable snapshot. This is the same as the
20101220-stable snapshot but with one additional patch:
[d534aa8]->[385ec31] iconv_open: Fix regression from 2010-12-04.
Tarball: http://erislabs.net/ianb/projects/gnulib/gnulib-20101221-stable.tar.gz
Gitweb: http://erislabs.net/g
> What do you think? Should libposix be LGPL or GPL?
This seems directly analogous to libc to me, ie, it should be LGPL.
On Wed, Dec 22, 2010 at 09:29:17AM +0100, Bruno Haible wrote:
> Then I thinnk it's worth creating a new one, yes.
Righto, I've just released a new snapshot. I'll send out
a separate announcement mail.
Ian.
--
Ian Beckwith - i...@erislabs.net - http://erislabs.net/ianb/
GPG fingerprint: AF6C C0F
Bruno Haible writes:
> What do you think? Should libposix be LGPL or GPL?
In case that you decide that it should be LGPL, then I give you
permission to relax the license of GPL modules that I have
written to LGPL, as necessary.
--
Ben Pfaff
http://benpfaff.org
Hi all,
Among the modules that will be part of libposix, i.e. that are listed as
gnulib modules for some POSIX functions or headers, the following are
currently under GPL license:
functions:
acosl
asinl
atanl
cosl
expl
isfinite
logl
sinl
sqrtl
tanl
File system related funct
Hi Jim, Eric,
> IMHO, those functions must never return in the unusual case for which
> they now call error and then exit. The failures are too fundamental[0],
> and we cannot require that all callers handle any new error code or
> interpret existing error codes differently, can we?
>
> [0] if o
On 12/22/10 13:57, Bruno Haible wrote:
> But I would find it good if
>
> - you would modify m4/vsnprintf.m4 like m4/snprintf.m4 - otherwise the
> gnulib modules 'vsnprintf' and 'snprintf' are inconsistent.
>
> - the files doc/posix-functions/{snprintf,vsnprintf}.texi were be
> updated
On 12/22/10 13:47, Bruno Haible wrote:
> Why do people do this? It appears to be slower than just calling
> asprintf, because it has to parse the format string and produce
> the expansion twice.
In the case of coreutils, the snprintf (NULL, 0, ) is invoked
just once, to find out the size of th
In keeping with the theme of documenting relatively-unimportant
Solaris bugs rather than working around them, I pushed this doc
fix, the need for which I found when running "make check" with
the latest coreutils.
Here's a simpler test case that illustrates the Solaris bug,
in case there's anybody
On 12/22/2010 03:19 PM, Jim Meyering wrote:
> Bruno Haible wrote:
>
>> Ping? No one wants to solve this? It's a critical issue for libposix.
>>
>> Eric Blake wrote:
>>> error() is not POSIX. Maybe the thing to do is figure out what in
>>> libposix is dragging in error(), and work on breaking that
Bruno Haible wrote:
> Ping? No one wants to solve this? It's a critical issue for libposix.
>
> Eric Blake wrote:
>> error() is not POSIX. Maybe the thing to do is figure out what in
>> libposix is dragging in error(), and work on breaking that dependency.
>> That way, a package using libposix th
Bruno Haible wrote:
> Eric Blake wrote:
>> one _very_ common use of snprintf is to call it with size 0 to see
>> how much to allocate, then allocate and call again.
>
> Why do people do this? It appears to be slower than just calling
> asprintf, because it has to parse the format string and produce
Ping? No one wants to solve this? It's a critical issue for libposix.
Eric Blake wrote:
> error() is not POSIX. Maybe the thing to do is figure out what in
> libposix is dragging in error(), and work on breaking that dependency.
> That way, a package using libposix then makes their own decision o
Hi Paul,
Eric Blake wrote:
> one _very_ common use of snprintf is to call it with size 0 to see
> how much to allocate, then allocate and call again.
Among all the
portability problems fixed by snprintf-posix, the return value for size
0 buffer makes the most sense to me to promote to plain snpri
Eric Blake wrote:
> one _very_ common use of snprintf is to call it with size 0 to see
> how much to allocate, then allocate and call again.
Why do people do this? It appears to be slower than just calling
asprintf, because it has to parse the format string and produce
the expansion twice.
==
* tests/test-posixtm.c: Add two tests, to highlight the
bug in Solaris 10 (and earlier) localtime. Gnulib doesn't work
around this bug; this is merely to document it.
---
ChangeLog|7 +++
tests/test-posixtm.c |6 ++
2 files changed, 13 insertions(+), 0 deletions(-)
di
On OSF/1 5.1 I'm seeing this test failure:
test-getlogin_r.c:76: assertion failed
sh: 363055 Abort - core dumped
FAIL: test-getlogin_r
The reason is that the OSF/1 getlogin_r() function produces a truncated
result when the buffer is not large enough. As if with strncpy. This
is not exactly a bug,
Hello Joachim,
> $ ./stdioext-flags
> #define _IOERR 0x40
> #define _IOREAD 0x80
> #define _IOWRT 0x4
> #define _IORW 0x100
> #define _IORW 0x100
>
> Very nice.
>
> Downloaded, unpacked, modified gllib/stdio-impl.h as per above, configured,
> compiled, checked, all 33 tests p
On OSF/1 5.1, the ptsname test fails:
test-ptsname.c:78: assertion failed
sh: 366922 Abort - core dumped
FAIL: test-ptsname
The reason is that for e.g. a master of "/dev/ptype" the ptsname function
returns the slave "/dev/pts/14" but our code expects "/dev/ttype". The
two file names are not the s
On OSF/1 5.1, the ttyname_r test fails:
test-ttyname_r.c:45: assertion failed
sh: 367584 Abort - core dumped
FAIL: test-ttyname_r
The reason is that ttyname_r stores its result in the buffer, ignoring
the buffer's size. This patch provides a workaround:
2010-12-22 Bruno Haible
ttyna
On OSF/1 5.1, I get these test failures:
test-rename.h:342: assertion failed
sh: 366977 Abort - core dumped
FAIL: test-rename
test-rename.h:342: assertion failed
sh: 366978 Abort - core dumped
FAIL: test-renameat
The reason are different errno values. The following patch fixes it for me.
OK to c
On 12/22/2010 08:31 AM, Bruno Haible wrote:
> On OSF/1 5.1, I get these test failures:
>
> test-rename.h:342: assertion failed
> sh: 366977 Abort - core dumped
> FAIL: test-rename
>
> test-rename.h:342: assertion failed
> sh: 366978 Abort - core dumped
> FAIL: test-renameat
>
> The reason are di
Eric Blake wrote:
> Fred Tydeman pointed out that since POSIX [MX] shading defers to C99
> Appendix F, which defers to IEEE 754, and IEEE 754 section 6.3 The Sign
> Bit states:
>
> ... and the sign of the result of the round floating-point number to
> integral value operation is the sign of the op
Hi Joachim,
> I believe I did this earlier and sent you some patches, back in early
> October this year and from my company email account (schm...@hp.com),
> in connection with getting ACL support to work for HP-NonStop.
Yes, but there were too many TODOs in these patches, and you didn't
use a te
Paul Eggert wrote:
> * doc/posix-functions/gai_strerror.texi: Return type is also an
> issue on Solaris 9 and earlier.
Same problem on AIX 7.1 and HP-UX 11.31.
2010-12-22 Bruno Haible
getaddrinfo: Update doc.
* doc/posix-functions/gai_strerror.texi: Return type is also differ
I discovered these issues when running "make check" with the
latest coreutils snapshot on Solaris 8 with Sun C 5.8. (This didn't
cause "make check" to fail, it just generated diagnostics.)
* doc/posix-functions/gai_strerror.texi: Return type is also an
issue on Solaris 9 and earlier.
* doc/posix-
Paul Eggert wrote:
> The name should be something like "ceil-ieee-fp", no?
I went for 'ceil-ieee'.
Here's the changes that I pushed (in chronological order):
Tests for module 'floor'.
* modules/floor-tests: New file.
* tests/test-floor1.c: New file, based on tests/test-f
Hi Ian,
Ian Beckwith wrote:
> > The effect of this bug are link errors on glibc systems and systems with
> > GNU libiconv installed [1].
>
> Damn, it was committed a couple of hours after I pulled. Is it worth
> creating a new snapshot with just that fix cherrypicked? It won't take
> long to crea
32 matches
Mail list logo
