Re: FAIL: test-vasprintf-posix failure on darwin12 cause

[Jack Howarth]

On Fri, Jun 28, 2013 at 11:25:26AM -0600, Eric Blake wrote:
> On 06/27/2013 08:29 PM, Jack Howarth wrote:
> >    I have identified the difference between the builds of m4 1.4.16 on 
> > darwin11,
> > which doesn't exhibit the test-vasprintf-posix failure in the m4 testsuite, 
> > and
> 
> Thanks for the report.  m4 1.4.16 uses an old version of gnulib; can you
> please retest with the latest m4.git:branch-1.4 contents?  If that fixes
> the problem (because it uses newer gnulib), then I have nothing further
> to do (except release m4 1.4.17 - still on my todo list); if it still
> reproduces, then we should take this report upstream to gnulib.

Eric,
   I am not having any luck with the bootstrap working if I do...

git clone git://git.savannah.gnu.org/m4.git
cd m4
bootstrap

It fails with...

Makefile.am:152: error: 'pkglibexecdir' is not a legitimate directory for 
'LTLIBRARIES'

This is against fink's autoconf 2.69 and automake 1.12. Can you email me a 
tarball of
the regenerated m4 trunk directory?
            Jack
ps Jeremy Huddleston Sequoia at Apple had the following observations...

-------------------------------------------------------------------------------------------------------------------------
The fact that result=0 is a good thing.  That conftest is producing a bitmask 
of bugs it hit.  In the case of Snow Leopard,
+it hit:

  /* This catches a FreeBSD 6.1 bug: it doesn't round.  */
  if (sprintf (buf, "%.2a %d", 1.51, 33, 44, 55) < 0
      || (strcmp (buf, "0x1.83p+0 33") != 0
          && strcmp (buf, "0x3.05p-1 33") != 0
          && strcmp (buf, "0x6.0ap-2 33") != 0
          && strcmp (buf, "0xc.14p-3 33") != 0))
    result |= 4;
  /* This catches a FreeBSD 6.1 bug.  See
     <http://lists.gnu.org/archive/html/bug-gnulib/2007-04/msg00107.html> */
  if (sprintf (buf, "%010a %d", 1.0 / 0.0, 33, 44, 55) < 0
      || buf[0] == '0')
    result |= 8;

And on Lion, it just hits the result=4 case
---------------------------------------------------------------------------------------------------------------------------
It looks like they're trying to catch the same bug as conftest.c but chose %.0a 
which revealed something different.

If we change 1.51 to 1.52, it passes … so this looks like a rounding issue.

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main() {
    char *result;
    int retval = asprintf (&result, "%.0a %d", 1.51, 33, 44, 55);

    printf("result: %s\n", result);

    assert(result != NULL);
    assert(strcmp (result, "0x2p+0 33") == 0 || strcmp (result, "0x3p-1 33") == 
0 || strcmp (result, "0x6p-2 33") == 0 ||
+strcmp (result, "0xcp-3 33") == 0);
    assert(retval == strlen (result));
    free(result);

    return 0;
}
--------------------------------------------------------------------------------------------------------------------------
It's not a numerics issue.  The actual bits in memory are correct.  It looks 
like just a formatting issue, so it's likely
+something in gdtoa.

conftest is correct in that we don't have *THAT* bug.
The test-vasprintf-posix in m4 incorrectly assumes we do have that bug because 
we fail that assert, but it's really tripping
+over this:

printf("%.0a\n", 1.51);
  -- SL:   0x2p+0
  -- Lion: 0x2p+0
  -- ML:   0x1p+0
  -- Cab:  0x1p+0

I'd recommend changing the m4 test from 1.51 to 1.52 and then possibly adding 
another check for this rounding bug if that
+matters to them.


> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>