Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

2017-09-12 Thread LRN 
On 9/12/2017 8:22 PM, Liu Hao wrote:
> On 2017/9/13 0:15, Eli Zaretskii wrote:
>>> You'd need to disassemble (or at least check with nm) the
>>> object/function to find out if it's calling __mingw_printf or regular
>>> printf, seems like emacs is using %lld and %I64 in different places.
>>
>> %lld is used for intmax_t values, %I64d is used for 64-bit values.
>>
>> Are you saying that MinGW64 doesn't support both %lld and %I64d?  If
>> so, under which conditions is each one supported?
>>
> 
> `printf()` provided by MSVCRT recognizes only `%I64d`, while 
> `__mingw_printf()` provided by MinGW-w64, which takes over `printf()` 
> due to `__USE_MINGW_ANSI_STDIO`, recognizes only `%lld`.

> This isn't related to the version of GCC, but to the version of 
> MinGW-w64 you have.
> 
These two things are orthogonal. GCC analyzes format strings and issues
warnings when they don't look right. print*() implementation (MSVCRT (without
MINGW_ANSI_STDIO), mingw (with MINGW_ANSI_STDIO), gnulib (when you use it), or
any other libc or utility library) analyzes format strings and expands the
field specifiers, producing the output. These two operate independently.

GCC looks at function attributes to get the idea what kind of formats it is
supposed to support.
"format (gnu_*printf, ...)" attributes support GNU formats.
"format (ms_*printf, ...)" attributes support MS formats.
"format (*printf, ...)" attributes are read as "ms_print*" when compiling for
Windows, and are read as "gnu_print*" when compiling for GNU.
What "GNU" and "MS" formats actually *mean* here (i.e. which kinds of
specifiers are valid or invalid) depends entirely on GCC.

Independently, actual print*() function implementations might support MS format
specifiers, or GNU format specifiers, or a mix of both (although it's usually
one or the other, with a bit of extras for compatibility in newer versions).

-- 
O< ascii ribbon - stop html email! - http://arc.pasp.de/


signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

2017-09-12 Thread Liu Hao 

On 2017/9/13 0:15, Eli Zaretskii wrote:

You'd need to disassemble (or at least check with nm) the
object/function to find out if it's calling __mingw_printf or regular
printf, seems like emacs is using %lld and %I64 in different places.


%lld is used for intmax_t values, %I64d is used for 64-bit values.

Are you saying that MinGW64 doesn't support both %lld and %I64d?  If
so, under which conditions is each one supported?



`printf()` provided by MSVCRT recognizes only `%I64d`, while 
`__mingw_printf()` provided by MinGW-w64, which takes over `printf()` 
due to `__USE_MINGW_ANSI_STDIO`, recognizes only `%lld`.


FWIW, with a C99-conforming `printf()` you can use `%jd` for `intmax_t`...


Check if keyboard.c and print.c is using __USE_MINGW_ANSI_STDIO
consistently.


The Emacs config.h defines __USE_MINGW_ANSI_STDIO, and all sources
include config.h.  So yes, this is used consistently.

What is the effect of __USE_MINGW_ANSI_STDIO on format specs
recognized by the MinGW64 GCC 7 compiler at compile time?



This isn't related to the version of GCC, but to the version of 
MinGW-w64 you have.


If `__USE_MINGW_ANSI_STDIO` is defined to something non-zero and 
 is included *after*  or , you get `%lld` for 
`PRIdMAX`, otherwise you get `%I64d`. This basically covers three cases:


Case 1:
```
#include 
#include 
int main(void){
  /* Calls `printf()` from MSVCRT.
 Outputs `I64d 42`  */
  printf("%s: %" PRIdMAX, PRIdMAX, INTMAX_C(42));
}
```

Case 2:
```
#define __USE_MINGW_ANSI_STDIO 1
#include 
#include 
int main(void){
  /* Calls `__mingw_printf()` from MinGW-w64.
 Outputs `lld 42`  */
  printf("%s: %" PRIdMAX, PRIdMAX, INTMAX_C(42));
}
```

Case 3:
```
#define __USE_MINGW_ANSI_STDIO 1
/* The user declares such a function {him,her}self...
   LD will resolve references to this function to the MSVCRT one,
   which accepts `%I64d`, rather than `%lld`.  */
extern int printf(const char *, ...);
#include 
int main(void){
  /* Calls `printf()` from MSVCRT.
 Outputs "I64d 42"  */
  printf("%s: %" PRIdMAX, PRIdMAX, INTMAX_C(42));
}
```

--
Best regards,
LH_Mouse


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

2017-09-12 Thread Eli Zaretskii 
> Date: Mon, 11 Sep 2017 23:46:00 +
> From: JonY via Mingw-w64-public 
> Cc: JonY 
> 
> > . GCC doesn't recognize the PRIdMAX format spec, defined in
> >   MinGW64 inntypes.h header as "lld";
> > . GCC doesn't recognize the MS native I64x format spec, either
> > 
> > Therefore, it seems like there's no way of invoking printf to print a
> > long long int data type without emitting a warning, and perhaps also
> > generating incorrect code.
> > 
> > Does Emacs do anything wrong in these cases?
> > 
> 
> You'd need to disassemble (or at least check with nm) the
> object/function to find out if it's calling __mingw_printf or regular
> printf, seems like emacs is using %lld and %I64 in different places.

%lld is used for intmax_t values, %I64d is used for 64-bit values.

Are you saying that MinGW64 doesn't support both %lld and %I64d?  If
so, under which conditions is each one supported?

> Check if keyboard.c and print.c is using __USE_MINGW_ANSI_STDIO
> consistently.

The Emacs config.h defines __USE_MINGW_ANSI_STDIO, and all sources
include config.h.  So yes, this is used consistently.

What is the effect of __USE_MINGW_ANSI_STDIO on format specs
recognized by the MinGW64 GCC 7 compiler at compile time?

Thanks.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

2017-09-11 Thread Eli Zaretskii 
> From: 
> Date: Tue, 12 Sep 2017 10:05:12 +1000
> 
> Not sure what to make of the format warnings (I'll leave that to others), 
> but I think the post that you cited does reveal an instance of Emacs doing 
> something wrong wrt the redefining of _WIN32_WINNT.
> This symbol appears to be redefined in Emacs source, having earlier been 
> defined in _mingw.h:
> 
> C:/projects/emacs/nt/addpm.c:42:0: warning: "_WIN32_WINNT" redefined
> 
> Unless it's a mistake for _mingw.h to define this symbol in the first place, 
> then I'm thinking that addpm.c should precede it's own definition with an 
> '#undef _WIN32_WINNT'.

As a subsequent message reveals, this was due to local patches of the
user, and so is not the problem.

The problem is with format specs.

Thanks.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

2017-09-11 Thread sisyphus1 
-Original Message- 
From: Eli Zaretskii

Sent: Tuesday, September 12, 2017 3:19 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] Problems with using printf format specs with GCC 
7



Does Emacs do anything wrong in these cases?


Not sure what to make of the format warnings (I'll leave that to others), 
but I think the post that you cited does reveal an instance of Emacs doing 
something wrong wrt the redefining of _WIN32_WINNT.
This symbol appears to be redefined in Emacs source, having earlier been 
defined in _mingw.h:


C:/projects/emacs/nt/addpm.c:42:0: warning: "_WIN32_WINNT" redefined

Unless it's a mistake for _mingw.h to define this symbol in the first place, 
then I'm thinking that addpm.c should precede it's own definition with an 
'#undef _WIN32_WINNT'.


Cheers,
Rob




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

2017-09-11 Thread JonY via Mingw-w64-public 
On 09/11/2017 05:19 PM, Eli Zaretskii wrote:
> Hi,
> 
> Kindly take a look at the issues with building current development
> sources of GNU Emacs with MinGW64, described here:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00171.html
> 
> The build emits a lot of warnings related to printf specifications for
> printing 64-bit integral values. From these warnings it sounds like
> there are at least two issues:
> 
> . GCC doesn't recognize the PRIdMAX format spec, defined in
>   MinGW64 inntypes.h header as "lld";
> . GCC doesn't recognize the MS native I64x format spec, either
> 
> Therefore, it seems like there's no way of invoking printf to print a
> long long int data type without emitting a warning, and perhaps also
> generating incorrect code.
> 
> Does Emacs do anything wrong in these cases?
> 

You'd need to disassemble (or at least check with nm) the
object/function to find out if it's calling __mingw_printf or regular
printf, seems like emacs is using %lld and %I64 in different places.

Check if keyboard.c and print.c is using __USE_MINGW_ANSI_STDIO
consistently.

> 
> Another problem to be taken up with MinGW64 developers is this:
> 
> CCLD addpm.exe
>   C:/projects/emacs/nt/addpm.c:42:0: warning: "_WIN32_WINNT" redefined
>#define _WIN32_WINNT _WIN32_WINNT_WIN7
> 
>   In file included from 
> C:/msys64/mingw64/x86_64-w64-mingw32/include/crtdefs.h:10:0,
>from 
> C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:9,
>from C:/projects/emacs/nt/addpm.c:37:
>   C:/msys64/mingw64/x86_64-w64-mingw32/include/_mingw.h:225:0: note: this is 
> the location of the previous definition
>#define _WIN32_WINNT 0x502


Seems to me like emacs addpm is defining it too late.


signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public