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?)

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?)

[Max Bowsher]

[-- Attachment #1: Type: text/plain, Size: 3778 bytes --]

Responses below

Max.

----- Original Message -----
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: "Max Bowsher" <maxb@ukf.net>; <cygwin@cygwin.com>
Sent: Sunday, March 03, 2002 9:20 PM
Subject: 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?)
>
>
>
>
> > -----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.

No, I was just mentioning another
situation in which the header files could be used.

> > 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

Yes - mklink2.c - relevant build output
below. Detecting -Wstrict-prototypes would be ideal, but I do not think
there is
such a feature in gcc. Which leaves the following possibilities:
1) Annoy the X people - get them to stick in some prototypes and casts, etc.
2) Rewrite mklink2.c as C++
3) Stop using -Wstrict-prototypes
4) Create a STRICT_PROTOTYPES_NEEDED define, and alter the headers to honour
it.
Umm...

gcc -c -g -O2 -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-st
rings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomm
ents ... mklink2.c
cc1.exe: warnings being treated as errors
In file included from
/home/max/cvsstuff/cygwin/src-work/winsup/w32api/include/windows.h:101,
                 from win32.h:34,
                 from mklink2.c:2:
/home/max/cvsstuff/cygwin/src-work/winsup/w32api/include/windef.h:203:
warning:function declaration isn't a prototype
/home/max/cvsstuff/cygwin/src-work/winsup/w32api/include/windef.h:204:
warning:function declaration isn't a prototype
/home/max/cvsstuff/cygwin/src-work/winsup/w32api/include/windef.h:205:
warning:function declaration isn't a prototype
make: *** [mklink2.o] Error 1



> > 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.

No problem

> Rob
>
>
>
>


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2688 bytes --]

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]

> -----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/

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?)

[Max Bowsher]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

> Hmm, does C++ support the same feature? If not then an ifdef __cplusplus
> might do it.

> Rob

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.

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

3) C, -Wstrict-prototypes in effect
        'int proc();' means: ditto AND causes a warning (which, since setup
is compiled with 'warnings as errors' on, stops the build)
        'int proc(void);' means: ditto

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.

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.


Max.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2688 bytes --]