-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functions without prorotypes cause -Wstrict-prototypes warnings #633
Comments
until upstream madler/zlib#633 is resolved
Fix an instance in libevent. Sink -Wno-deprecated-non-prototype into zlib, it's the only remaining library where this warning fires. (upstream bug madler/zlib#633) Bug: 1314867 Change-Id: I2547ba1b358ab90ec6dece4f0879b2ebe6f59820 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3615937 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Arthur Eubanks <aeubanks@google.com> Cr-Commit-Position: refs/heads/main@{#998593}
Fix an instance in libevent. Sink -Wno-deprecated-non-prototype into zlib, it's the only remaining library where this warning fires. (upstream bug madler/zlib#633) Bug: 1314867 Change-Id: I2547ba1b358ab90ec6dece4f0879b2ebe6f59820 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3615937 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Arthur Eubanks <aeubanks@google.com> Cr-Commit-Position: refs/heads/main@{#998593} NOKEYCHECK=True GitOrigin-RevId: cbba1d4d16d3dfeb51421749cafa34c2666f8b26
Fix an instance in libevent. Sink -Wno-deprecated-non-prototype into zlib, it's the only remaining library where this warning fires. (upstream bug madler/zlib#633) Bug: 1314867 Change-Id: I2547ba1b358ab90ec6dece4f0879b2ebe6f59820 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3615937 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Arthur Eubanks <aeubanks@google.com> Cr-Commit-Position: refs/heads/main@{#998593} NOKEYCHECK=True GitOrigin-RevId: cbba1d4d16d3dfeb51421749cafa34c2666f8b26
Fix an instance in libevent. Sink -Wno-deprecated-non-prototype into zlib, it's the only remaining library where this warning fires. (upstream bug madler/zlib#633) Bug: 1314867 Change-Id: I2547ba1b358ab90ec6dece4f0879b2ebe6f59820 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3615937 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Arthur Eubanks <aeubanks@google.com> Cr-Commit-Position: refs/heads/main@{#998593} NOKEYCHECK=True GitOrigin-RevId: cbba1d4d16d3dfeb51421749cafa34c2666f8b26
I "fixed" those warnings in a local copy of zlib (in wasm/emsdk those are errors). |
#667 is an improvement but there are still many As the tip of the iceberg:
|
@Markus87 https://github.com/Markus87/zlib master branch fixes all Clang warnings! @madler It would be great to merge that change:) I understand that there may be straggling systems which do not support ANSI function declarations but some script (converse of |
* reinstate strict-prototype warning * More fixes * Need to keep the warning disabled for zlib madler/zlib#633 Co-authored-by: Jan Kotas <jkotas@microsoft.com>
I do not plan to remove the pre-ISO C compatibility at this time. I would recommend simply turning off that warning. By the way, every function does have an ISO C prototype that precedes it, if it is an ISO C compiler. The complaint is not even correct. |
If and when C2X is final and removes K&R function definitions, then I will remove them from zlib. I will leave this issue open until C2X is final. |
@AaronBallman may comment on the state of K&R function definitions. |
They were removed for C2x (WG14 N2841 and WG14 N2432) which is just coming up to the Committee Draft balloting stage (basically, one step before voting the standard out). Unless there is a national body comment which convinces WG14 to revert the changes, this will be in C2x. Given that K&R C functions without prototypes have been obsolescent in C since C was standardized by ISO (so 30+ years of "not a best practice"), I would be surprised if that would happen, but it is still a possibility. We should know for sure by the end of 2023 at the absolute latest.
That doesn't mean the things being diagnosed aren't being declared without a prototype. That syntax is broken by C2x, so the preceding prototypes don't matter. The diagnostic looks correct to me from the places I spot-checked, such as https://github.com/madler/zlib/blob/master/uncompr.c#L27 and https://github.com/madler/zlib/blob/master/crc32.c#L117 -- that code is obsolescent C and won't compile in C2x. |
Yes, I understand that the proposed change is to make the K&R syntax obsolete. However the text of the warning is incorrect, since those are not function declarations without a prototype. The warning should instead say something like function definitions with identifier lists are not permitted in C2X. |
K&R C functions have always been obsolete (see C89 3.9.5p1: "The use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators) is an obsolescent feature."). The change to C2x (not just proposed but already accepted by the committee) is to reuse that design space.
Please see C89 3.1.2.1p1: "(A function prototype is a declaration of a function that declares the types of its parameters.)" (The same text is in C17 6.2.1p2, which might be easier to find a copy of than C89.) You can also see this in the function call expression wording (C17 6.5.2.2p8) which says: "No other conversions are performed implicitly; in particular, the number and types of arguments are not compared with those of the parameters in a function definition that does not include a function prototype declarator." The functions I cited do not use a function prototype declarator, they use an identifier list and a separate declaration list. |
They have been deprecated, not obsolete, where by obsolete, I mean they would simply not be allowed, resulting in an error, not a warning. Maybe there's a better word. Perhaps forbidden. Those functions do in fact each have a prototype using the ISO format that precede the K&R declaration. So they are not functions without a prototype. By the way, this is a question just for my curiosity in case you know. I get that the use of declarations after a function parameter list will be forbidden. However they talk about "reusing" that design space. What would they reuse it for? |
[citation needed] (I think you're maybe talking about type composition rules, which is not where the diagnostic is coming from. There's literally no way to spell
|
|
I don't know that I have more to add to the conversation to try to clarify the situation, so I'll bow out at this point. |
As another compiler engineer, I can perhaps clarify: I think the confusion here is the difference between 'function' and 'function declaration' (and lesser-so, function definition). I believe the diagnostic is correct, since it is talking about the latter. To Clarify: In @madler 's example, that function DOES have a prototype available. However, the diagnostic is talking about the 'function declaration', of which line 2 DEFINITELY does not have a valid prototype. IMO, if you are willing to have line#1 in a program (meaning you are using a compiler that supports ANSI declarations), I don't see a reason to not just specify the definition the same way. Any compilers that can parse the first declaration (basically all compilers that implement "The C Programming Language" 2nd Edition by K&R) would ALSO be able to parse the 2nd if given a prototype. However, a compiler that parses the 1st declaration doesn't necessarily parse the 2nd. As far as:
You've already done so, no pre-ANSI C (what I suspect you meant?) compiler can compile zlib as it sits. |
…OTYPE The zlib project has issue madler/zlib#633 to document its continued use of old K&R-style function definitions. Suggested by: delphij@ Sponsored by: Netflix
zlib still uses K&R-style function declarations. As of clang 15, these are warned about by default, as they've been removed in the latest draft of C2x; this results in thousands(?) of lines of warnings when building zlib in-tree. An issue has been filed at madler/zlib#633, but the author has stated that they are unwilling to change this until C2x has actually been published. For now, just silence those warnings when building zlib. Differential Revision: https://phabricator.services.mozilla.com/D169842
zlib still uses K&R-style function declarations. As of clang 15, these are warned about by default, as they've been removed in the latest draft of C2x; this results in thousands(?) of lines of warnings when building zlib in-tree. An issue has been filed at madler/zlib#633, but the author has stated that they are unwilling to change this until C2x has actually been published. For now, just silence those warnings when building zlib. Differential Revision: https://phabricator.services.mozilla.com/D169842
zlib will fix this issue later (see madler/zlib#633). For now we will just turn off the warning.
* Suppress numerous libz warnings zlib will fix this issue later (see madler/zlib#633). For now we will just turn off the warning. * Fix Windows build
Really? How much did they try? It couldn't be simpler to work around this issue. As I suggested above, simply turn off the warning: I have pushed a commit on the develop branch that adds this work around to configure. 5799c14 The next version of zlib will remove the K&R declarations entirely. |
Looking forward to the new zlib. Do you have the plan when the new version will be released? @madler |
Soon. |
As suggested in madler/zlib#633. Future versions of zlib may fix this issue.
Neither Assuming that the next release is v1.2.14, v1.2.14 will be the first release fixing these warnings. edit: There is no v1.2.14. v1.3 (09155ea) contains the fixes. |
* Suppress numerous libz warnings zlib will fix this issue later (see madler/zlib#633). For now we will just turn off the warning. * Fix Windows build
As of Clang 14.0.0, compiling zlib with -Wstrict-prototypes is warning free.
The next Clang release 15.0.0 will include https://reviews.llvm.org/D122895 which has improved diagnostics. Notably: the new
-Wdeprecated-non-prototype
is enabled by default which warns many declarations in zlib:There are also a few
-Wstrict-prototypes -Wno-deprecated-non-prototype
diagnostics.Note:
-pedantic
will imply-Wstrict-prototypes
.As of GCC 11, its
-Wstrict-prototypes
warns about some declarations (a small subset of Clang's list):The text was updated successfully, but these errors were encountered: