Paul Eggert <[EMAIL PROTECTED]> writes:
> 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 ag
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I propose to move these modules to modules/crypto/
I've done that now. I'm not sure whether to also move the *.{c,h}
files to lib/crypto/, so I'll wait with that for a while.
/Simon
Simon Josefsson wrote:
> > I propose to move these modules to modules/crypto/
>
> I've done that now.
May I ask to put the 'memxor' module back to the top level? It is an
independently useful utility. It can be used in implementations of
Common Lisp's bit-xor function, or in GF(2)^n vector arithm
This module determines the physical temperature of the CPU. Or, if unavailable,
the temperature of the motherboard, as an approximation.
It would also be nice to have a function that returns the temperature of the
rechargeable battery. Does someone have a Linux laptop? Can you run the
'sensors' pr
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > I propose to move these modules to modules/crypto/
>>
>> I've done that now.
>
> May I ask to put the 'memxor' module back to the top level? It is an
> independently useful utility. It can be used in implementations of
> Commo
On Mar 30, 2007, at 19:51, Paul Eggert wrote:
Geoff Clare <[EMAIL PROTECTED]> writes:
Paul Eggert <[EMAIL PROTECTED]> wrote, on 30 Mar 2007:
Picky, picky. Let me restate it as "if the code ... outputs
"SSIZE_MAX wrong" (through normal execution, not undefined
behaviour),
Fine, but the po
directory is /home/k/ka/karl
Two levels is a bit much, I agree.
has no benefit
Well, I think there is a small benefit to having smaller directories (in
whatever scheme) than one gigantic directory, even if it is nothing
beyond "subdirectories for the sake of subdirectories". Technically
Paul Eggert said:
> Fine, but the point is that there's no portable way for an application
> to determine whether adding 1 to a ssize_t variable will have "normal
> execution" if the variable's value is SSIZE_MAX. This is regardless
> of whether SSIZE_MAX is the maximum value representable in a ss
Paul Eggert said:
>> 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 created with more than 2*
