Alain Guibert wrote:
> > The behaviour change in "checking for long long int" is intended. The
> > users of the gnulib macros now expect to be able to use long longs in
> > preprocessor directives (even if there are some known bugs with values
> > outside the 32-bit 'int' range).
>
> But the prepr
Hello,
I'm about to release coreutils-6.11, so this may really be the final call.
If you have changes for gnulib or coreutils that you think should be in
a stable release, please let me know ASAP (like within an hour or two).
Currently, I'm planning to use gnulib v0.0-513-g2e89567, which has
unde
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> [This issue arose in examination of bug 22924 against GNU PSPP,
>> which may be viewed at https://savannah.gnu.org/bugs/?22924.]
>>
>> The %e format implemented by gnulib's vasnprintf (when
>> NEED_PRINTF_DOUBLE is defined) does not r
Ben Pfaff wrote:
> By adding a printf
> around here, I can see that floorlog10 chooses an exponent of 3.
The floorlog10 function was intended to return a result with at most 10^-7
error. There was a bug here too (I confused log and log2.) This fixes it.
2008-04-19 Bruno Haible <[EMAIL PROTECTE
Ben Pfaff wrote:
> [This issue arose in examination of bug 22924 against GNU PSPP,
> which may be viewed at https://savannah.gnu.org/bugs/?22924.]
>
> The %e format implemented by gnulib's vasnprintf (when
> NEED_PRINTF_DOUBLE is defined) does not round properly in all
> cases. Here is one exampl
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I'm publishing this mainly so that people who care about the affected
>> platforms can investigate further.
>
> As a first step to that: the list of failing tests:
>
> $ grep '^FAIL:' * | sort -k2
> go.2008.04.14.07.01.55.log:FAIL: 2g
