From efefed244f4b1b46c3b5de639108b9ea1b06179b Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Sun, 7 Apr 2024 06:37:05 -0700 Subject: [PATCH] Format fixes in thanks-for-fixes.md --- thanks-for-help.html | 13 ++++++++++--- thanks-for-help.md | 8 ++++---- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/thanks-for-help.html b/thanks-for-help.html index fbb965865..935cea2b8 100644 --- a/thanks-for-help.html +++ b/thanks-for-help.html @@ -190,16 +190,23 @@ be kept in:

char x {sizeof( double(%s,%D)(*)())

This does mean that there cannot be a second arg to main() -as clang requires that to be a char ** and thecharredefined would not allow this. Some versions of clang say thatmain()must have either 0, 2 or 3 args but these versions do not object to 1 arg. However as thecharmacro seems more obscure and it is possible that a new version of clang will be even more strict theint iparameter inmain()was moved to be insidemain(), set to non-zero (settingito 0 will not work). This waymain()` has zero +as clang requires that to be a char ** and the char redefined would not +allow this. Some versions of clang say that main() must have either 0, 2 or 3 +args but these versions do not object to 1 arg. However as the char macro +seems more obscure and it is possible that a new version of clang will be even +more strict the int i parameter in main() was moved to be inside main(), +set to non-zero (setting i to 0 will not work). This is way main() has zero args.

Observe how on line 29 there is a call to main() which does pass in a parameter. It has never been observed to be an error to pass in too many parameters to a function (main() or otherwise - it warns with other functions but does not appear to with main()) but only that main() itself has a certain number of args (in some versions) and that the first arg is an int and -the others are char **s. This is why the arg was removed and the call tomain()was not updated beyond what had to be done to fix it for compilers that do not support-traditional-cpp`.

+the others are char **s. This is why the arg was removed and the call to +main() was not updated beyond what had to be done to fix it for compilers that +do not support -traditional-cpp.

If the ANSI C committee or a new version of clang messes this up (both of which -seems possible) it is easy to fix but it is hoped that this won’t happen.

+seem possible) it is easy to fix but it is hoped that this won’t happen.

Originally Yusuke supplied a patch so that this entry would compile with gcc - but not clang - or at least some versions.

To see the difference from start to fixed:

diff --git a/thanks-for-help.md b/thanks-for-help.md index 3600745b1..047768ee0 100644 --- a/thanks-for-help.md +++ b/thanks-for-help.md @@ -89,12 +89,12 @@ be kept in: ``` This does mean that there cannot be a second arg to `main()` -as clang requires that to be a `char ** and the `char` redefined would not +as clang requires that to be a `char **` and the `char` redefined would not allow this. Some versions of clang say that `main()` must have either 0, 2 or 3 args but these versions do not object to 1 arg. However as the `char` macro seems more obscure and it is possible that a new version of clang will be even more strict the `int i` parameter in `main()` was moved to be inside `main()`, -set to non-zero (setting `i` to 0 will not work). This way `main()` has zero +set to non-zero (setting `i` to 0 will not work). This is way `main()` has zero args. Observe how on line 29 there is a call to `main()` which does pass in a @@ -102,12 +102,12 @@ parameter. It has never been observed to be an error to pass in too many parameters to a function (`main()` or otherwise - it warns with other functions but does not appear to with `main()`) but only that `main()` itself has a certain number of args (in some versions) and that the first arg is an `int` and -the others are `char **s. This is why the arg was removed and the call to +the others are `char **`s. This is why the arg was removed and the call to `main()` was not updated beyond what had to be done to fix it for compilers that do not support `-traditional-cpp`. If the ANSI C committee or a new version of clang messes this up (both of which -seems possible) it is easy to fix but it is hoped that this won't happen. +seem possible) it is easy to fix but it is hoped that this won't happen. Originally [Yusuke](#yusuke) supplied a patch so that this entry would compile with gcc - but not clang - or at least some versions.