Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <002301c1c364$a20a8970$d1228d09@wdg.uk.ibm.com> From: "Max Bowsher" To: 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?) Date: Mon, 4 Mar 2002 10:09:11 -0000 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_001F_01C1C364.A13F4A30"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Mar 2002 10:09:12.0583 (UTC) FILETIME=[A20A8970:01C1C364] ------=_NextPart_000_001F_01C1C364.A13F4A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Responses below Max. ----- Original Message ----- From: "Robert Collins" To: "Max Bowsher" ; 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 AT ukf DOT net] > > Sent: Sunday, March 03, 2002 9:36 PM > > To: cygwin AT cygwin DOT 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 > > > > ------=_NextPart_000_001F_01C1C364.A13F4A30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIijCCAr8w ggIooAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwSjELMAkGA1UEBhMCVUsxHjAcBgNVBAMTFU1heCBC b3dzaGVyIChSb290IENBKTEbMBkGCSqGSIb3DQEJARYMbWF4YkB1a2YubmV0MB4XDTAyMDIxMzEz MjA0MloXDTAzMDIxMzEzMjA0MlowSjELMAkGA1UEBhMCVUsxHjAcBgNVBAMTFU1heCBCb3dzaGVy IChSb290IENBKTEbMBkGCSqGSIb3DQEJARYMbWF4YkB1a2YubmV0MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCvJQJS//LZa4lT4ZRe3SKcfco5BE5vmQdp70grCuEFOJl5/Kkhb6p0PZXkkgA3 thAFZqB/KOAOF6hwodazx+esVfV9PIKkTG+KhXaQvmmN01SjLRqg7anDxSTDJJf8mwE6YJtVJ03C 8aZm4TXXjenr+cIIUSPcOuRPUZYgQAh0fwIDAQABo4G0MIGxMAsGA1UdDwQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MB0GA1UdDgQWBBQ3L9Yr4kasW7LXjBABnnzw4Kz5TjByBgNVHSMEazBpgBQ3L9Yr 4kasW7LXjBABnnzw4Kz5TqFOpEwwSjELMAkGA1UEBhMCVUsxHjAcBgNVBAMTFU1heCBCb3dzaGVy IChSb290IENBKTEbMBkGCSqGSIb3DQEJARYMbWF4YkB1a2YubmV0ggEAMA0GCSqGSIb3DQEBBQUA A4GBAFLF2iYrCF9dYm2bOuFP2cUUzeHzPrpnJLVvSriegYckvYIyMQbBf1DMvjuruh6SKxeQYjz5 wMKyG/B1kCTarDaz0N/YYmpnmq/sx6g0acNe/J0oPd5zxNH2Oa7kf7PjtnxhyJG3psyUAIS1ePO5 YxUcJUfcobBSEQdJ4yfAnCf3MIIC2zCCAkSgAwIBAgIBATANBgkqhkiG9w0BAQUFADBQMQswCQYD VQQGEwJVSzEkMCIGA1UEAxMbTWF4IEJvd3NoZXIgKEVtYWlsIFJvb3QgQ0EpMRswGQYJKoZIhvcN AQkBFgxtYXhiQHVrZi5uZXQwHhcNMDIwMjEzMTMyODA5WhcNMDMwMjEzMTMyODA5WjBPMQswCQYD VQQGEwJVSzEjMCEGA1UEAxQaTWF4IEJvd3NoZXIgKG1heGJAdWtmLm5ldCkxGzAZBgkqhkiG9w0B CQEWDG1heGJAdWtmLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5j0b8K8SJpRsErvl iFmhwml/nnYVJfMVi105HLix9sNjYZccl3FSn9w0ghVQbLCsgIpwI8XFGirCbL6CEF+5dmmGL//3 +wazwOakI+BQBX4yGwnSnNSkgtcW6jhbyjKPMrA4pMX8urKdRLsGkwrduTNQRaS3xAMBLfdCBJk6 nqUCAwEAAaOBxTCBwjAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQmoaNsNxILLHDF4PHVWadROFddiTByBgNVHSMEazBpgBRuq2TkAovVqlSO cVqj0e0nYe5OfqFOpEwwSjELMAkGA1UEBhMCVUsxHjAcBgNVBAMTFU1heCBCb3dzaGVyIChSb290 IENBKTEbMBkGCSqGSIb3DQEJARYMbWF4YkB1a2YubmV0ggEBMA0GCSqGSIb3DQEBBQUAA4GBANfK JjcZ4VWugIDoc20n0UgeowVdgJVxdjZ5FGb302L/ihgFpGnx7Wfw1GmvK4W7YQS6X6gJoYCcmtAM LV+GpPLAvPnGJcPvK13F0lhEKwslYQF0RBSYzZasX8jF+dbVGNOsU2UgDVFUKITk9UZ2K2GoXzVq ZNN3bMxEJZqxzW5vMIIC5DCCAk2gAwIBAgIBATANBgkqhkiG9w0BAQUFADBKMQswCQYDVQQGEwJV SzEeMBwGA1UEAxMVTWF4IEJvd3NoZXIgKFJvb3QgQ0EpMRswGQYJKoZIhvcNAQkBFgxtYXhiQHVr Zi5uZXQwHhcNMDIwMjEzMTMyMDQ3WhcNMDMwMjEzMTMyMDQ3WjBQMQswCQYDVQQGEwJVSzEkMCIG A1UEAxMbTWF4IEJvd3NoZXIgKEVtYWlsIFJvb3QgQ0EpMRswGQYJKoZIhvcNAQkBFgxtYXhiQHVr Zi5uZXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOMLbe/pTtdIyBaN8snkYvW7tGabtQb4 4iJ3ZHFUpB1G6v9rpLqDgyvC3SvZI/1w+tliSfY88HVYvG9qjRHapw+YHyBzGkMy+yqoq3lihtOA c3V8VYbREgGvCodSPs5/kZUPoL4JME86MWe5wxd/IclDg08IV3rBYV5YgELWDR3fAgMBAAGjgdMw gdAwCwYDVR0PBAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBRuq2TkAovVqlSOcVqj0e0nYe5OfjByBgNVHSMEazBpgBQ3L9Yr4kas W7LXjBABnnzw4Kz5TqFOpEwwSjELMAkGA1UEBhMCVUsxHjAcBgNVBAMTFU1heCBCb3dzaGVyIChS b290IENBKTEbMBkGCSqGSIb3DQEJARYMbWF4YkB1a2YubmV0ggEAMA0GCSqGSIb3DQEBBQUAA4GB AIhvdbvjxuM1hF5EeRCvd6h21yTvjctwO1Preokrv0ukVkhYNvNOaciOV4VGx0tCrBIp88vjNTND 1H2Ih1V9e+fg+zmccSqY6SMDkGfbsmP8bh8IhQezGlKElyHcXknE3VpFT70FALI6XOB5EC1vV0QR Zzs0ZRCnuLQf9F0hptWyMYIBuDCCAbQCAQEwVTBQMQswCQYDVQQGEwJVSzEkMCIGA1UEAxMbTWF4 IEJvd3NoZXIgKEVtYWlsIFJvb3QgQ0EpMRswGQYJKoZIhvcNAQkBFgxtYXhiQHVrZi5uZXQCAQEw CQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w MjAzMDQxMDA5MTFaMCMGCSqGSIb3DQEJBDEWBBQc36gAckpLrCIU2zvSzVOvnJyxsjBbBgkqhkiG 9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0BAQEFAASBgCqCgvz9z9lB128P 7nDHZ52foB3KO1Z7VXHSJMfVjy7VkLeeHsp4FgQGkhQeQ7GqF94A3zL0C2wG1uCi5P0LVQsQumIc i9zVULecsCJE7aljNR5h2nAS70GC6XzKKxtWnTNmqOcYqnGqYNKob22OKbneymJij5HcSxPe34IL /mKzAAAAAAAA ------=_NextPart_000_001F_01C1C364.A13F4A30--