From: Paul G. <pga...@qw...> - 2001-09-18 22:53:00
|
On 18 Sep 2001 at 13:00, the Illustrious Danny Smith wrote: > > Hi > > I have uploaded tow sets of patches to SF for silencing -pedantic > warnings in w32api. One is misc bits like comma following last enum, the > other is for long long typedefs. I would appreciate comments. > > I have a third set of patches, that I am a bit hesitant to submit. > These involve use of bitfields in structures. (see attached err.log from > w32api/lib/test.c - after applying the first two sets of patches). I can see why you would hesitate. > > These warnings may be useful in that they flag potential problems with > gcc struct layout vs. "native" structure layout and thus I don't think > they should be silenced (yet). I agree. I think the documentation should state something about the fact that Win32api is _not_ ansi standard. Nor do I feel that any efforts should be made to correct non-ansi (add pedantic) warnings where the Win32api is concerned. > Maybe, they should be silenced if > -fnative-struct switch is given to gcc, but that means we need a cpp > spec defining __NATIVE_STRUCT__ when the switched is used. I think I can agree on this point. Problem is defining __NATIVE_STRUCT__ since I am under the impression that the abstraction for what is "native" is pretty vague where MS kernels are concerned. Paul G. |
From: Paul G. <pga...@qw...> - 2001-09-18 22:53:13
|
On 18 Sep 2001 at 13:00, the Illustrious Danny Smith wrote: > > Hi > > I have uploaded tow sets of patches to SF for silencing -pedantic > warnings in w32api. One is misc bits like comma following last enum, the > other is for long long typedefs. I would appreciate comments. > > I have a third set of patches, that I am a bit hesitant to submit. > These involve use of bitfields in structures. (see attached err.log from > w32api/lib/test.c - after applying the first two sets of patches). I can see why you would hesitate. > > These warnings may be useful in that they flag potential problems with > gcc struct layout vs. "native" structure layout and thus I don't think > they should be silenced (yet). I agree. I think the documentation should state something about the fact that Win32api is _not_ ansi standard. Nor do I feel that any efforts should be made to correct non-ansi (add pedantic) warnings where the Win32api is concerned. > Maybe, they should be silenced if > -fnative-struct switch is given to gcc, but that means we need a cpp > spec defining __NATIVE_STRUCT__ when the switched is used. I think I can agree on this point. Problem is defining __NATIVE_STRUCT__ since I am under the impression that the abstraction for what is "native" is pretty vague where MS kernels are concerned. Paul G. |
From: <dan...@ya...> - 2001-09-18 23:43:16
|
> > I have a third set of patches, that I am a bit hesitant to submit. > > These involve use of bitfields in structures. (see attached err.log > from > > w32api/lib/test.c - after applying the first two sets of patches). > > I can see why you would hesitate. > > > > These warnings may be useful in that they flag potential problems > with > > gcc struct layout vs. "native" structure layout and thus I don't > think > > they should be silenced (yet). > > I agree. I think the documentation should state something about the > fact that Win32api is > _not_ ansi standard. Nor do I feel that any efforts should be made > to correct non-ansi (add > pedantic) warnings where the Win32api is concerned. > The problem with not marking these non-ANSI decls as __extension__ is that a flood of warnings can "hide" the warnings produced by user code: it is too easy to ignore all warnings as YAMSEX (yet another MS extension) > > > Maybe, they should be silenced if > > -fnative-struct switch is given to gcc, but that means we need a > cpp > > spec defining __NATIVE_STRUCT__ when the switched is used. > > I think I can agree on this point. Problem is defining > __NATIVE_STRUCT__ since I am > under the impression that the abstraction for what is "native" is > pretty vague where MS kernels are > concerned. > I have done quick test of the w32api structs with bit-fields: the sizes of the structs are the same with -fnative-struct and -fgcc-struct with mingw and these match the sizes produced by Borland compiler and MSVC++6. I have not tested the offsets of fields within the structs, but looking at them quickly and with my understanding of the MS rules, I don't see a problem. The "native" struct name is Donn Terry's choice. Here is his explanation from http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00577.html <quote> Details: MSVC (and maybe other) compilers don't align bitfields to match any of the "normal" gcc modes. In addition, there are good arguments on both sides of whether "gnu" or "native" packing should be provided (and what the default should be). Rather than making a commitment... I chose the names "native" and "gnu" rather than "native" and "no-native" or some other variation both because it seemed more extensible and because it asserted what was being done directly. <end quote> Danny http://travel.yahoo.com.au - Yahoo! Travel - Got Itchy feet? Get inspired! |
From: Paul G. <pga...@qw...> - 2001-09-19 01:10:55
|
Hi folks, On 19 Sep 2001 at 9:43, the Illustrious Danny Smith wrote: > > > > I have a third set of patches, that I am a bit hesitant to submit. > > > These involve use of bitfields in structures. (see attached err.log > > from > > > w32api/lib/test.c - after applying the first two sets of patches). > > > > I can see why you would hesitate. > > > > > > These warnings may be useful in that they flag potential problems > > with > > > gcc struct layout vs. "native" structure layout and thus I don't > > think > > > they should be silenced (yet). > > > > I agree. I think the documentation should state something about the > > fact that Win32api is _not_ ansi standard. Nor do I feel that any > > efforts should be made to correct non-ansi (add pedantic) warnings > > where the Win32api is concerned. > The problem with not marking these non-ANSI decls as __extension__ is > that a flood of warnings can "hide" the warnings produced by user code: > it is too easy to ignore all warnings as YAMSEX (yet another MS > extension) Mmm...ok, I begin to have a better idea of the considerations here. The term "pragma" keeps coming up for me. What about forcing a GCC #pragma which eliminates generation of certain warnings? If I understand the term properly, this could be used by anyone who is doing the sort of thing that the original poster was talking about, ie. compile a Win32api application with -pedantic - Wall, adding a #pragma which eliminates a specific set of warnings output at preprocessing time. > > > > > > Maybe, they should be silenced if > > > -fnative-struct switch is given to gcc, but that means we need a > > cpp > > > spec defining __NATIVE_STRUCT__ when the switched is used. > > > > I think I can agree on this point. Problem is defining > > __NATIVE_STRUCT__ since I am > > under the impression that the abstraction for what is "native" is > > pretty vague where MS kernels are concerned. > > > > > I have done quick test of the w32api structs with bit-fields: the sizes > of the structs are the same with -fnative-struct and -fgcc-struct with > mingw and these match the sizes produced by Borland compiler and > MSVC++6. I have not tested the offsets of fields within the structs, > but looking at them quickly and with my understanding of the MS rules, I > don't see a problem. Ok. I am inclined to believe that the offsets of fields within the structs will not cause problems. Mumit might be able to better answer this though. > > The "native" struct name is Donn Terry's choice. Here is his > explanation from > > http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00577.html > > <quote> > Details: > MSVC (and maybe other) compilers don't align bitfields to match > any of the "normal" gcc modes. In addition, there are good arguments on > both sides of whether "gnu" or "native" packing should be provided (and > what the default should be). Rather than making a commitment... > > I chose the names "native" and "gnu" rather than "native" and > "no-native" or some other variation both because it seemed more > extensible and because it asserted what was being done directly. > <end quote> Ok. I will think of it in these terms. Paul G. > > Danny > > http://travel.yahoo.com.au - Yahoo! Travel > - Got Itchy feet? Get inspired! > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > |