RE: w32api bugfix (was: Currently, CVS setup.exe does not compile, due to warnings with 'warnings as errors' in effect. How best to change code to avoid warnings?)

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Max Bowsher [mailto:maxb@ukf.net] 
> Sent: Sunday, March 03, 2002 9:36 PM
> To: cygwin@cygwin.com
> Subject: w32api bugfix (was: Currently, CVS setup.exe does 
> not compile, due to warnings with 'warnings as errors' in 
> effect. How best to change code to avoid warnings?)
> 
> 
> > Hmm, does C++ support the same feature? If not then an ifdef 
> > __cplusplus might do it.
> 
> Unfortunately not - the problem is the differing 
> interpretation of the line 'typedef int (WINAPI *FARPROC)();' 
> in 3 sets of circumstances:
> 
> 1) C++
>         'int proc();' and 'int proc(void);' are synonyms. No problem.

Does the error trigger under g++ ? IIRC your original post correctly, it
does. If so, then gcc's warning is flawed.
 
> 2) C, -Wstrict-prototypes NOT in effect
>         'int proc();' means: use no compiler type checking 
> for the parameters if proc
>         'int proc(void);' means: proc takes no parameters

Ah, this is the killer then. Do we actually hit this during a C file
compilation? We've only a couple of C files - autoload and mklink2.  I
wonder if we can detect that -Wstrict-prototypes is on in the header -
something like
#if !pramga(strict-on) || defined (_cplusplus)
...
#endif
 
> Summary:
> The construct 'typedef int (WINAPI *FARPROC)();' in w32api 
> causes an error with -Wstrict-prototypes -Werror. This can be 
> worked around by adding 'void' in the empty brackets.
> Downside:
> This breaks C code where people were using the w32api types 
> FARPROC, NEARPROC, PROC, to call procedures without 
> typechecking the arguments. I think this is totally 
> irrelevant, as deliberately bypassing the compiler type 
> checking is very silly, and I doubt anyone does that anymore.
 
Actually, they do. Someone turned the (void) off again after I'd put it
in there because the X code needed it.

> Anyway, before I go submitting a patch which breaks backward 
> compatibility, even in such a rare and unused case, I want to 
> raise this issue here.

Thank you.

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/