fix all -Wdeprecated-non-prototype warnings

[rosasco-wk]

I'd like to fix all the compiler warnings in Zlib that result from the -Wdeprecated-non-prototype flag.

Compiler

~/src/zlib (master)  > ${FUCHSIA_DIR}/./prebuilt/third_party/clang/linux-x64/bin/clang --version                                                                                                                [10:42:08]
Fuchsia clang version 16.0.0 (https://llvm.googlesource.com/llvm-project 039b969b32b64b64123dce30dd28ec4e343d893f)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Output

Warnings generated by issuing make test are attached.

deprecated.txt

Suggested Style

In its current form, the code uses separate type declaration lines including a comment e.g.:
unsigned dist; /* distance of matched string */

Moving the type unsigned into the declaration alone leaves the comment that follows unaccounted for.

Below is a suggested example diff for how to get rid of the deprecation warnings and retain the comments:

~/src/zlib (master)  > git diff trees.c                                                                                                                                                                         [10:45:32]
diff --git a/trees.c b/trees.c
index f73fd99..9e4e358 100644
--- a/trees.c
+++ b/trees.c
@@ -1011,11 +1011,11 @@ void ZLIB_INTERNAL _tr_flush_block(s, buf, stored_len, last)
 /* ===========================================================================
  * Save the match info and tally the frequency counts. Return true if
  * the current block must be flushed.
+ *
+ * |dist| - distance of matched string
+ * |lc|   - match length-MIN_MATCH or unmatched char (if dist==0)
  */
-int ZLIB_INTERNAL _tr_tally (s, dist, lc)
-    deflate_state *s;
-    unsigned dist;  /* distance of matched string */
-    unsigned lc;    /* match length-MIN_MATCH or unmatched char (if dist==0) */
+int ZLIB_INTERNAL _tr_tally (deflate_state *s, unsigned dist, unsigned lc)
 {
     s->sym_buf[s->sym_next++] = dist;
     s->sym_buf[s->sym_next++] = dist >> 8;

Comments

@madler please review the suggested style above and accept or propose a preferred style. Cheers.

[madler]

I do not plan to remove the pre-ISO C compatibility at this time. I would recommend simply turning off that warning.

[rosasco-wk]

On Thu, Oct 6, 2022 at 4:02 PM Mark Adler ***@***.***> wrote: I do not plan to remove the pre-ISO C compatibility at this time. I would recommend simply turning off that warning.

Is this because there are toolchains that would break if the interfaces are updated ? I’d like to address this because one-off build settings or toolchain requirements for individual third_party repos creates an ever increasing entropy and maintenance burden to the clients of the library. I’m not sure if it was clear in my earlier email Mark: I was offering to update these interfaces and because the change is so pervasive, wanted to get your consent as to the style employed in this change.

…

— Reply to this email directly, view it on GitHub <#702 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANYYDOLZI5NHJ54FGHAUBDDWB5K6VANCNFSM6AAAAAAQG7VTEY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[madler]

"not at this time" means not for the next version. I need to get a version out to fix some things, so it's not the time to break stuff. If C2X does in fact deprecate K&R function declarations completely, then I will eventually need to get rid of them. (clang seems to be jumping the gun here — it hasn't even happened yet. I think the C2X finalization is supposed to be at the end of this year.)

As for a style, surely the easiest thing to do would be to just remove the function arguments and close parenthesis and change the semicolons to commas, except the last semicolon becomes the new close parenthesis. Could be done with a script.

Come to think of it, there already is a Perl script to do this in the zlib distribution, called zlib2ansi. I haven't tried it in a long time, so I'm not certain it works.

[rosasco-wk]

By style I was referring to how you wanted the existing inline comments per parameter to appear in the updated, ANSI-compliant functions. Are bugs normally closed in zlib that aren't applicable to the next version ? (i.e. the description of not at this time)

…

On Sat, Oct 8, 2022 at 9:14 PM Mark Adler ***@***.***> wrote: "not at this time" means not for the next version. I need to get a version out to fix some things, so it's not the time to break stuff. If C2X does in fact deprecate K&R function declarations completely, then I will eventually need to get rid of them. (clang seems to be jumping the gun here — it hasn't even happened yet. I think the C2X finalization is supposed to be at the end of this year.) As for a style, surely the easiest thing to do would be to just remove the function arguments and close parenthesis and change the semicolons to commas, except the last semicolon becomes the new close parenthesis. Could be done with a script. Come to think of it, there already *is* a Perl script to do this in the zlib distribution, called zlib2ansi. I haven't tried it in a long time, so I'm not certain it works. — Reply to this email directly, view it on GitHub <#702 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANYYDONS2XD5QMMW4ZLY3VTWCJBDVANCNFSM6AAAAAAQG7VTEY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[madler]

By style I was referring to how you wanted the existing inline comments per parameter to appear in the updated, ANSI-compliant functions. Are bugs normally closed in zlib that aren't applicable to the next version ? (i.e. the description of not at this time)

That's what I answered. The comments should appear just as they do now. All you need to do is change the semicolons to commas or a close parenthesis.

I don't understand your question.

[rosasco-wk]

On Tue, Oct 11, 2022 at 11:42 AM Mark Adler ***@***.***> wrote: By style I was referring to how you wanted the existing inline comments per parameter to appear in the updated, ANSI-compliant functions. Are bugs normally closed in zlib that aren't applicable to the next version ? (i.e. the description of not at this time) That's what I answered. The comments should appear just as they do now. All you need to do is change the semicolons to commas or a close parenthesis. I don't understand your question.

If I read the comments correctly, it appears that the issue I filed to modernize the interfaces was closed because this update wasn't applicable for the next version of zlib. I would expect that the issue I filed would remain open (i.e. it's still valid regardless of the current state of the tree and the next version) and the pull request for the changes made to address that issue wouldn't be approved until after all of the churn you described had settled down. —

…

Reply to this email directly, view it on GitHub <#702 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANYYDON3KLBAT5FQFRKN3C3WCWYJJANCNFSM6AAAAAAQG7VTEY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[madler]

Ah. I closed this because this is a duplicate of #633 . I didn't realize that I had closed that one as well, so I just reopened it.