Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Vincent Lefevre]

On 2020-01-11 16:33:30 +0100, Marco Bodrato wrote:
> Ciao,
> 
> Il Ven, 10 Gennaio 2020 5:04 pm, Vincent Lefevre ha scritto:
> > On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote:
> >> Can you please try with the development version?
> 
> > I get the following error:
> 
> > gmp_vsnprintf return value wrong
> 
> ... because there was an error in the process of cross-compilation...
> 
> > Is there a way to tell GMP's configure that vsnprintf is missing,
> > so that HAVE_VSNPRINTF is not defined?
> 
> Configure should check for it, but checking is not possible for
> cross-compilations. Should we add an option for this case?

Perhaps.

> It would be nice if the autotools give support for an optional "emulation
> environment", for a better configuration and an easier testing process...

I wonder why the #define's in config.h are not protected by #ifndef,
so that the user could set the value to 0. I mean that the general
form for macros set by default should have been:

#ifndef HAVE_VSNPRINTF
#define HAVE_VSNPRINTF 1
#elif HAVE_VSNPRINTF == 0
#undef HAVE_VSNPRINTF
#endif

FYI, about the snprintf bug in MinGW:

  https://sourceforge.net/p/mingw-w64/bugs/709/
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000101

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Marco Bodrato]

Ciao,

Il Ven, 10 Gennaio 2020 5:04 pm, Vincent Lefevre ha scritto:
> On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote:
>> Can you please try with the development version?

> I get the following error:

> gmp_vsnprintf return value wrong

... because there was an error in the process of cross-compilation...

> Is there a way to tell GMP's configure that vsnprintf is missing,
> so that HAVE_VSNPRINTF is not defined?

Configure should check for it, but checking is not possible for
cross-compilations. Should we add an option for this case?
It would be nice if the autotools give support for an optional "emulation
environment", for a better configuration and an easier testing process...

> BTW, I still notice in printf/vasprintf.c:
>
>   ret = vsnprintf (d->buf + d->size, space, fmt, ap);
>   if (ret == -1)
> {
>   ASSERT (strlen (d->buf + d->size) == space-1);
>   ret = space-1;
> }

I'll look into that.

Ĝis,
m

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Vincent Lefevre]

On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote:
> This code was changed.
> 
> https://gmplib.org/repo/gmp/rev/d6b57abdad8e
> 
> Can you please try with the development version?

I get the following error:

FAIL: t-printf
==

gmp_vsnprintf return value wrong
  fmt   |%Mu|
  bufsize   2
  got   |12!7|
  want  |1|
  want full |127|
  ret   -1
  want_len  3
FAIL t-printf.exe (exit status: 3)

Note: The issue can be detected with the absence of \0 just before
the sentinel (but a \0 should be written there before the call to
make sure...).

But I now think that this is a bug that should be fixed in MinGW
since the intended behavior now seems to conform to the C standard.
FYI, the __USE_MINGW_ANSI_STDIO macro is now internal and should
no longer be used:

  
https://fr.osdn.net/projects/mingw/lists/archive/users/2019-January/000199.html

Is there a way to tell GMP's configure that vsnprintf is missing,
so that HAVE_VSNPRINTF is not defined?

BTW, I still notice in printf/vasprintf.c:

  ret = vsnprintf (d->buf + d->size, space, fmt, ap);
  if (ret == -1)
{
  ASSERT (strlen (d->buf + d->size) == space-1);
  ret = space-1;
}

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Vincent Lefevre]

On 2020-01-10 08:44:13 +0100, Niels Möller wrote:
> Vincent Lefevre  writes:
> 
> > Under Debian/unstable, I've configured GMP with:
> >
> >   ./configure --host=i686-w64-mingw32 --disable-shared --enable-assert
> >
> > but "make check LOG_COMPILER=wine" gives:
> >
> > FAIL: t-printf
> > ==
> >
> > snprntffuns.c:79: GNU MP assertion failed: strlen (d->buf) == avail-1
> > FAIL t-printf.exe (exit status: 3)
> >
> > The failing code is
> >
> >   ret = vsnprintf (d->buf, avail, fmt, ap);
> >   if (ret == -1)
> > {
> >   ASSERT (strlen (d->buf) == avail-1);
> >   ret = avail-1;
> > }
> 
> Does it make a difference if you add CPPFLAGS=-D__USE_MINGW_ANSI_STDIO
> to the configuration?

I get no failures.

> > I don't understand the ASSERT. A return value of -1 means an output
> > error, so that you cannnot deduce anything about the contents stored
> > in d->buf.
> 
> Non-standard versions of snprintf returned -1 for truncation (including
> old glibc, and likely windows libc too). And the way I read the ASSERT,
> it says that truncation is the only expected reason for vsnprintf to
> return -1. What was fmt? It would be helpful to understand the reason
> for the -1 return in the failing case.

Here's what I get for i = 3 to 7:

i = 3, limb = 7 (1)
avail = 2, fmt = "%lu", ret = 1, buf = "7"

i = 4, limb = 15 (1)
avail = 2, fmt = "%lu", ret = 2, buf = "15!"

i = 5, limb = 31 (1)
avail = 2, fmt = "%lu", ret = 2, buf = "31!"

i = 6, limb = 63 (1)
avail = 2, fmt = "%lu", ret = 2, buf = "63!"

i = 7, limb = 127 (1)
avail = 2, fmt = "%lu", ret = -1, buf = "12!7"

So, one gets a truncation because avail = 2 is too small for 127,
and like with old glibc, one gets ret = -1. GMP expects that a \0
at the end is written in this case, and perhaps old glibc did, but
not mingw.

Note that the "7" after the sentinel is just old data. If I add

  d->buf[avail+1] = '\0';

before the

  ret = vsnprintf (d->buf, avail, fmt, ap);

I get:

avail = 2, fmt = "%lu", ret = -1, buf = "12!"

So, without -D__USE_MINGW_ANSI_STDIO, this is non-conforming (perhaps
for compatibility if vsnprintf was implemented in MS Windows before
it got standardized in ISO C99). I think that a fix should be easy:
write a \0 before the sentinel, and if ret = -1 and this \0 has been
replaced by vsnprintf, this probably means truncation.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Niels Möller]

Vincent Lefevre  writes:

> Under Debian/unstable, I've configured GMP with:
>
>   ./configure --host=i686-w64-mingw32 --disable-shared --enable-assert
>
> but "make check LOG_COMPILER=wine" gives:
>
> FAIL: t-printf
> ==
>
> snprntffuns.c:79: GNU MP assertion failed: strlen (d->buf) == avail-1
> FAIL t-printf.exe (exit status: 3)
>
> The failing code is
>
>   ret = vsnprintf (d->buf, avail, fmt, ap);
>   if (ret == -1)
> {
>   ASSERT (strlen (d->buf) == avail-1);
>   ret = avail-1;
> }

Does it make a difference if you add CPPFLAGS=-D__USE_MINGW_ANSI_STDIO
to the configuration?

> I don't understand the ASSERT. A return value of -1 means an output
> error, so that you cannnot deduce anything about the contents stored
> in d->buf.

Non-standard versions of snprintf returned -1 for truncation (including
old glibc, and likely windows libc too). And the way I read the ASSERT,
it says that truncation is the only expected reason for vsnprintf to
return -1. What was fmt? It would be helpful to understand the reason
for the -1 return in the failing case.

> /* Define to 1 if you have the `vsnprintf' function and it works properly. */
> #define HAVE_VSNPRINTF 1

I guess it's hard for configure to check for proper return value when cross
compiling.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs