Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> It is not completely obvious to me that one can link things together
> where some parts want to compliant stdio and some other parts want a
> non-compliant stdio.

I don't really know how that magic works, but my guess guess is that
it's per compilation unit, so "printf" in the source code will refer to
one of two different functions depending on which magic preprocessor
symbols were defined when stdio.h was parsed. (Which then might violate
C standard rules on function pointer comparison...)

Anyway, I don't think we can try to force any windows program linking
with gmp to define __USE_MINGW_ANSI_STDIO in each and every compilation
unit, so I hope things will work well enough with a mix.

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

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  #if defined(__WIN32__) && define (__GNUC__)
  #define __USE_MINGW_ANSI_STDIO 1
  #endif
  
  I'd guess there are plenty of windows programs that depend on the
  non-standard behavior. So bug-compatibility makes some sense. But we
  don't want it.
  
It is not completely obvious to me that one can link things together
where some parts want to compliant stdio and some other parts want a
non-compliant stdio.

If it is possible, I agree with your proposal.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Torbjörn Granlund]

Claude Heiland-Allen  writes:

  > Could the macro __USE_MINGW_ANSI_STDIO be relevant?
  
  Yes, perfect!  I did
  
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO ./configure
  --host=x86_64-w64-mingw32 --prefix=$HOME/win64
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make -j 8
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make install
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make check
  
  and the whole test suite passes now.
  
User choice is great; one can choose between malfunctioning libc or
explicitly ask for a correct one.

Should we pass this option for mingw on GMP's configure.ac?
Or do people expect broken libc on this platform...?


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Claude Heiland-Allen]

Hi Marc,

On 31/03/17 00:27, Marc Glisse wrote:
> On Thu, 30 Mar 2017, Vincent Lefevre wrote:
> 
>> On 2017-03-30 10:52:33 +0100, Claude Heiland-Allen wrote:
>>> The failing source code is:
>>>
>>>   /* EOF for no matching */
>>>   {
>>> char buf[128];
>>> ret = gmp_sscanf ("   ", "%s", buf);
>>> ASSERT_ALWAYS (ret == EOF);
>>> ret = fromstring_gmp_fscanf ("   ", "%s", buf);
>>> ASSERT_ALWAYS (ret == EOF);
>>> if (option_libc_scanf)
>>>   {
>>> ret = sscanf ("   ", "%s", buf);
>>> ASSERT_ALWAYS (ret == EOF);
>>> ret = fun_fscanf ("   ", "%s", buf, NULL);
>>> ASSERT_ALWAYS (ret == EOF);
>>>   }
>>>   }
>>>
>>> Commenting out the asserts and 'if' and inserting debugging printf()
>>> statements gives:
>>>
>>> gmp_sscanf() ret = 0
>>> fromstring_gmp_fscanf() ret = 0
>>> sscanf() ret = 0
>>  
>>> fun_fscanf() ret = 0
>>
>> The initial issue is the 0 returned by sscanf(). Then GMP is consistent
>> with the C implementation.
>>
>> Though the C standard may be ambiguous, 0 is not possible as a return
>> value. Thus this is a bug in the C library (or compiler).
> 
> Could the macro __USE_MINGW_ANSI_STDIO be relevant?

Yes, perfect!  I did

CPPFLAGS=-D__USE_MINGW_ANSI_STDIO ./configure
--host=x86_64-w64-mingw32 --prefix=$HOME/win64
CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make -j 8
CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make install
CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make check

and the whole test suite passes now.

Thanks,


Claude
-- 
https://mathr.co.uk
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Marc Glisse]

On Thu, 30 Mar 2017, Vincent Lefevre wrote:


On 2017-03-30 10:52:33 +0100, Claude Heiland-Allen wrote:

The failing source code is:

  /* EOF for no matching */
  {
char buf[128];
ret = gmp_sscanf ("   ", "%s", buf);
ASSERT_ALWAYS (ret == EOF);
ret = fromstring_gmp_fscanf ("   ", "%s", buf);
ASSERT_ALWAYS (ret == EOF);
if (option_libc_scanf)
  {
ret = sscanf ("   ", "%s", buf);
ASSERT_ALWAYS (ret == EOF);
ret = fun_fscanf ("   ", "%s", buf, NULL);
ASSERT_ALWAYS (ret == EOF);
  }
  }

Commenting out the asserts and 'if' and inserting debugging printf()
statements gives:

gmp_sscanf() ret = 0
fromstring_gmp_fscanf() ret = 0
sscanf() ret = 0

 

fun_fscanf() ret = 0


The initial issue is the 0 returned by sscanf(). Then GMP is consistent
with the C implementation.

Though the C standard may be ambiguous, 0 is not possible as a return
value. Thus this is a bug in the C library (or compiler).


Could the macro __USE_MINGW_ANSI_STDIO be relevant?

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

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Vincent Lefevre]

On 2017-03-30 10:52:33 +0100, Claude Heiland-Allen wrote:
> The failing source code is:
> 
>   /* EOF for no matching */
>   {
> char buf[128];
> ret = gmp_sscanf ("   ", "%s", buf);
> ASSERT_ALWAYS (ret == EOF);
> ret = fromstring_gmp_fscanf ("   ", "%s", buf);
> ASSERT_ALWAYS (ret == EOF);
> if (option_libc_scanf)
>   {
> ret = sscanf ("   ", "%s", buf);
> ASSERT_ALWAYS (ret == EOF);
> ret = fun_fscanf ("   ", "%s", buf, NULL);
> ASSERT_ALWAYS (ret == EOF);
>   }
>   }
> 
> Commenting out the asserts and 'if' and inserting debugging printf()
> statements gives:
> 
> gmp_sscanf() ret = 0
> fromstring_gmp_fscanf() ret = 0
> sscanf() ret = 0
  
> fun_fscanf() ret = 0

The initial issue is the 0 returned by sscanf(). Then GMP is consistent
with the C implementation.

Though the C standard may be ambiguous, 0 is not possible as a return
value. Thus this is a bug in the C library (or compiler).

If %s can match an empty sequence of non-white-space characters, then
the return value should be 1 (contrary to %[, there is no mention of
"nonempty" for %s in the text of the standard). Otherwise, this is an
input failure because the end of the input string is reached before
the %s matching:

  4  The fscanf function executes each directive of the format in turn.
 When all directives have been executed, or if a directive fails
 (as detailed below), the function returns. Failures are described
 as input failures (due to the occurrence of an encoding error or
 the unavailability of input characters), or matching failures (due
 to inappropriate input).

And in case of input failure before the first conversion has completed
(which is the case here), EOF is returned:

 16  The fscanf function returns the value of the macro EOF if an
 input failure occurs before the first conversion (if any) has
 completed. Otherwise, the function returns the number of input
 items assigned, which can be fewer than provided for, or even
 zero, in the event of an early matching failure.

-- 
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: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Claude Heiland-Allen]

On 30/03/17 14:12, Torbjörn Granlund wrote:
> It is not realistic for us to work on this problem as there are
> countless of things which might be wrong.

Good point.  I don't think my project in question that uses GMP needs
those functions anyway, so I'll leave it uninvestigated.

Thanks for the reply,


Claude
-- 
https://mathr.co.uk

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