Re: [MinGW-dvlpr] Re: [Fwd: w32api and gcc -pedantic]

[Paul G. <pga...@qw...>]

Hi folks,

On 17 Apr 2001, at 6:59, the Illustrious Danny Smith wrote:

> 
> --- Earnie Boyd <ear...@ya...> wrote: > 
> > 
> > -------- Original Message --------
> > Subject: Re: [Fwd: w32api and gcc -pedantic]]
> > Date: Mon, 16 Apr 2001 11:13:11 -0400
> > From: Christopher Faylor <cg...@re...>
> > Reply-To: cyg...@cy...
> > To: Cygwin Patches <cyg...@cy...>
> > References: <3AD...@ya...>
> > <116...@lo...>
> > 
> > On Mon, Apr 16, 2001 at 06:25:20PM +0400, egor duda wrote:
> > >Warnings should stay as long as we talk about user's code. But when
> > >it comes to system header files, i believe (and my reading of various
> > >existing standard headers make me believe so) that we should work
> > >around such warnings. For example, many standard headers contain
> > >fragments like this one:
> > >
> > >#if defined(__STDC__) || defined(__cplusplus)
> > >#define SIG_DFL ((void (*)(int))0)
> > >#define SIG_IGN ((void (*)(int))1)
> > >#define SIG_ERR ((void (*)(int))-1)
> > >#else
> > >#define SIG_DFL ((void (*)())0)
> > >#define SIG_IGN ((void (*)())1)
> > >#define SIG_ERR ((void (*)())-1)
> > >#endif
> > >
> > >so, it doesn't matter if we use compiler (or compile-time switch for
> > >compiler) that doesn't support some feature or fires a warning seeing
> > >it -- standard headers will compile cleanly.
> > >
> > >if running gcc with '-pedantic' define some macro that could be
> > >tested in standard headers, we could use it. But, afaik, it doesn't
> > >define anything like it. Instead, gcc info recommends marking such
> > >code fragments explicitly as '__extension__'.
> > >
> > >My point is: standard headers shouldn't produce warnings whether you
> > >compile them with new version of compiler or old one. It should
> > >matter for user's code not for standard headers. 

	I agree, no sense in producing standard header warnings.  I can think 
of only one possible exception having to do with win32api ACL (OS 
Specific) extensions...keeping the standard functions/headers 
transparent is the preferred approach, imho.

> > IMO, system headers should not produce warnings, ever.
> > 

	The developer should, however, be made aware of the reasons for this 
in order to save time when it comes to meeting project deadlines.


> > cgf
> > 
> 
> I'm convinced, and withdraw my objection.
> The only thing that bothers me is that the sometimes, when it is
> convenient, the w32api is called "system".  When it is not convenient,
> it is called other things which the rules of polite conversation prevent
> me from repeating. Danny

	I hear what you are saying Danny.  Wish there were more abstraction 
between OS variations on the win32api.  Such vagueness re: OS 
variations, I suppose, is another "feature" of the win32api (The "Ghost 
of Elvis Presley" walks in, and begins mindlessly repeating, "Thank 
you, Microsoft, thank you very much")...


	Peace,

		Paul G.


Nothing real can be threatened.
    Nothing unreal exists.