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*
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
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
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
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
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
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
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
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
