Bruno Haible <[EMAIL PROTECTED]> writes:
> In other words, the standard allows the function to be buggy...
The wording you quoted is talking about something else. It is
referring to the behavior of the VAX floating point unit, where the
hardware representation that one thinks would represent -0.
Bruno Haible <[EMAIL PROTECTED]> writes:
>> Perhaps it's the "else #else" which confused you? (It certainly confuses
>> me...)
>
> If it confuses even you, then it's late time to make this code more
> readable!
OK, thanks, I installed this. It's not exactly what you recommended, but
it should b
> I'm happy to assign copyright to the FSF.
>
> I've included the .c and the .h files.
>
This already exists:
http://www.gnu.org/software/gnulib/MODULES.html#module=quote
--
Eric Blake
I've written a useful convienience routine that I think would be
useful for gnulib. It's called str_quotify, and it converts a char
pointer and a length into a C-style backslash quoted string. It's
very useful for debugging output and such.
I'm happy to assign copyright to the FSF.
I've include
AIX iconv is unusable: it does not report conversion failures.
2007-03-29 Bruno Haible <[EMAIL PROTECTED]>
* m4/iconv.m4 (AM_ICONV_LINK): Require AC_CANONICAL_HOST. Test against
a bug in AIX iconv().
*** m4/iconv.m4 18 Jan 2005 13:07:56 - 1.10
--- m4/iconv.m4 30 Mar 20
Paul Eggert wrote:
> vasnprintf.c should do this:
>
> if (copysignl (1, arg) < 0)
> {
> sign = -1;
> arg = -arg;
> }
>
> I think it's much cleaner. And the code is smaller on my platform,
> anyway: no function call is generated for copysignl.
In case the ldexpl replacement is needed on an i386 platform (it will be
needed e.g. on NetBSD/i386), it needs to fpu control word twiddling.
Also, a small optim: The last squaring of 'factor' is not needed.
2007-03-29 Bruno Haible <[EMAIL PROTECTED]>
* lib/ldexpl.c: Include fpucw.h.
On AIX, not only frexpl() is completely broken, but also ldexpl(). So it
needs a substitute. I am therefore pulling it out of the 'mathl' module.
2007-03-29 Bruno Haible <[EMAIL PROTECTED]>
* modules/ldexpl: New file.
* m4/ldexpl.m4: New file.
* lib/math_.h (ldexpl): Def
Since the function frexpl() is missing a declaration on some systems, the
test whether it works needs to declare it.
2007-03-29 Bruno Haible <[EMAIL PROTECTED]>
* m4/frexpl.m4 (gl_FUNC_FREXPL_WORKS): Declare frexpl.
*** m4/frexpl.m425 Mar 2007 22:21:06 - 1.3
--- m4/fr
Paul Eggert wrote:
> > And if priv_allocset succeeds, it will not cache the result,
> > but instead redo the same system calls next time. Is this intentional?
>
> I don't follow this point; it looks to me like it caches.
When priv_allocset is callable, the function looks like this:
bool
can_wr
The "right" way to test for -0 versus +0 is to use copysign.
For example, instead of this:
if (arg < 0.0L)
{
sign = -1;
arg = -arg;
}
else if (arg == 0.0L)
{
/* Distinguish 0.0L and -0.0L. */
static long
On 3/29/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
On AIX 5.1, with gnulib as of today (29 March) the test-stat-time test fails.
More precisely, on a 'jfs2' file system, the test fails in the third ASSERT
of test_mtime. I get these time stamps:
[...]
I can see two ways to fix the test:
- Turn
Bruno Haible <[EMAIL PROTECTED]> writes:
> - The code uses the Solaris 10 APIs. How about also using the Linux API
> for "capabilities" - capget() - that was added in Linux 2.2 and glibc-2.1.x?
Thanks, I wasn't aware of this API. That would be nice to add.
> - If priv_allocset fails, the func
"Clive D.W. Feather" <[EMAIL PROTECTED]> writes:
> ptrdiff_t has to be able to hold the largest difference between two
> pointers; it is a signed type.
The C standard does not require this. It allows an implementation,
for example, where size_t is 64 bits, ptrdiff_t is 32, and objects can
be cre
James Youngman wrote:
> Sorry about those defects. Thanks for cleaning up the mess :)
One more item: On AIX, there is no .
2007-03-29 Bruno Haible <[EMAIL PROTECTED]>
* tests/test-stat-time.c: Include , not .
*** tests/test-stat-time.c 27 Mar 2007 18:51:18 - 1.3
--- te
Eric Blake <[EMAIL PROTECTED]> writes:
> 2007-03-25 Eric Blake <[EMAIL PROTECTED]>
>
> * lib/acl-internal.h: Remove redundant include.
> (ACL_NOT_WELL_SUPPORTED): Also filter on EBUSY, returned by
> Cygwin when a file is locked.
Thanks, I installed that, along with the obvious
Bruno Haible <[EMAIL PROTECTED]> writes:
> * lib/regexec.c (merge_state_with_log): Make static.
Thanks, please install.
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Possibly the bug-workaround for unistd.h should only be enabled if the
> sysexits module is present, otherwise the unistd-module would always
> touch non-standardized namespaces which seems wrong.
I agree. I'd rather not use the sysexits module, whic
On AIX 5.1, with gnulib as of today (29 March) the test-stat-time test fails.
More precisely, on a 'jfs2' file system, the test fails in the third ASSERT
of test_mtime. I get these time stamps:
$ stat t-stt-stamp1
File: `t-stt-stamp1'
Size: 0 Blocks: 0 IO Block: 4096 r
Jeff Blaine <[EMAIL PROTECTED]> writes:
> Red Hat Linux v3
> GCC 3.2.3 (as provided with above)
>
> ...
> checking whether getcwd handles long file names properly...
>
> Sits there forever.
It shouldn't actually sit there forever. Just for a very long time.
> Here's a strace of the looping conf
Not to be low-tech, but how about 26 subdirectories a..z?
That way, if I know the name, I know the subdirectory.
Simon Josefsson wrote:
> Done!
Karl noticed that this now causes a divergence with libintl's sources. Better
avoid it, like this:
2007-03-29 Bruno Haible <[EMAIL PROTECTED]>
* lib/vasprintf.c [IN_LIBINTL]: Include different specification file.
* lib/asprintf.c [IN_LIBINTL]: Lik
"James Youngman" <[EMAIL PROTECTED]> writes:
> On 3/27/07, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> - /* Birth time not supported. */
>> - pts->tv_sec = 0;
>> - pts->tv_nsec = 0;
>> - return 0;/* result is not valid */
>> + /* Birth time is not supported. Set tv_sec to
On 3/29/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
That's true. I guess it depends on the refactor discriminator.
Either based or content (crypto, unicode, string-functions,
math-functions, etc), or type (header, file, etc). To me, all the
crypto stuff seems self-contained and uninteresting
Bruno Haible <[EMAIL PROTECTED]> writes:
Like others, I like the idea of grouping but I'm afraid the initial
group proposal didn't sound that felicitous.
> The expected benefit is that
> 1) that people looking for a particular function and whether gnulib
> support it can find it immediatel
Bruno Haible wrote:
> Simon Josefsson wrote:
>> Refactoring seems like a good thing. Your proposed two modules/
>> directory split didn't strike me as the obvious way to go, but I
>> haven't really thought about it.
>
> Yes, a categorization according to topic, like James proposes, was
> also my
Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
> ...
>> I'm Cc'ing Jim because he is the owner of the md5 module. I believe
>> md5 is the only crypto-related module that I'm not the owner of. Jim,
>> are you ok with moving the md5 module to modules/crypto/
Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
> I'm Cc'ing Jim because he is the owner of the md5 module. I believe
> md5 is the only crypto-related module that I'm not the owner of. Jim,
> are you ok with moving the md5 module to modules/crypto/ together with
> the rest of the modules?
Hi Simo
Bruno Haible <[EMAIL PROTECTED]> writes:
>> I propose to move these modules to modules/crypto/
>
> Maybe it is wise to consider the dependency structure when creating this
> subdirectory? The 'md4' module is not dependent on the other crypto modules,
> and the other crypto modules don't depend on
On 3/29/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
I don't think it does. One would need to pass extra -I flags to 'aclocal'.
gnulib-tool doesn't do this yet.
It would be useful to findutils if it did though, I think. Findutils
currently does this:
aclocal -I m4 -I gnulib/m4
James.
Simon Josefsson wrote:
> Refactoring seems like a good thing. Your proposed two modules/
> directory split didn't strike me as the obvious way to go, but I
> haven't really thought about it.
Yes, a categorization according to topic, like James proposes, was
also my first thought. But some modules
James Youngman wrote:
> Perhaps something like this?
>
> posix - for implementing POSIX functionality on broken systems
> glibc - for gnulib's implementation of functions available on GNU
> systems but not posix (i.e. for things we should sometimes sync with
> glibc)
This will increase the lookup
Bruno Haible <[EMAIL PROTECTED]> writes:
> Objections?
Refactoring seems like a good thing. Your proposed two modules/
directory split didn't strike me as the obvious way to go, but I
haven't really thought about it.
Btw, a lot of modules would go away of I moved all crypto-related
stuff into a
On 3/29/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
gnulib now has more than 600 modules, some of which are already in
subdirectories. Still, there are more than 500 modules at the top level.
I propose two new subdirectories in the modules directory, with the aim of
clarity:
1) a subdirectory
34 matches
Mail list logo
