Stricter C99 warnings, strict prototypes for primitives list

[MisterDA]

This PR is a simplified version of #11763, where we don't use the actual types of the primitives when generating the list of primitives, because we end up casting the primitives to a default type anyway (as noted by David Allsopp).
I've retained some of the changes I made to the Makefile, because I think they're easier to understand than the current version.

cc @dra27 @xavierleroy, reviewers of the previous PR.

[shindere]

Many thanks for your work here, @MisterDA. I really like the style of the PR, how everything is nicely explained. Thanks! Regarding your first commit, my main concern is that the list of files to scan for primitives is now duplicated and I am wondering whether this duplication could be aovided. On the one hand, thelist of files to scan is in `runtime/gen_primitives.sh` to make Dune's life easier but on the other hand, from the persepctive of the main build system, it would be better to have the list of files only in the root Makefile and then passed to the script as arguemnts on its command-line. That way, the script could be called from anywhere, which is not possible at the moment. Also, another problem with duplicating the list is that the two versions will have to be kept in sync, which be fragile and error-prone. Would it make sense to scan `runtime/*.c` rather than being explicit about the list? If that's the case, could this please be done in the Makefile, something like ``` runtime_PRIMITIVES = $(wildcard runtime/*.c) ``` and then in `runtime/gen_primitives.sh` you would have a for loop that iterates over `$@` or `$*`, I never know which is the right one. I am assuming that Dune would also be able to expand `runtime/*.c`, wouldn't it? Re: the rule that generates `runtime/primitives`, I'd like to suggest that you put all the prerequisites on one line and change their order: ``` runtime/primitives.new: runtime/gen_primitives.sh $(runtime_PRIMITIVES) ``` Then, if the names of C sources to scan are passed to the script the command could be written as `$^ > $@` and if, for some reason we have to call the script without argumemnts, then the command would be `$< > $@` so it's simpler no matter how you handle the list of source files to parse. Regarding your second commit, perhaps you could use the `SED` build variable to call the sed that has been detected by configure. In addition to that, you could add the `LC_ALL=C` bi to the definition of the `SED` variable in `Makefile.build_config.in`. Concretely speaking, the line you would add there would be: ``` SED=LC_ALL=C @Sed@ ``` In a similar way, you could define ``` SED=LC_ALL=C tr ``` In theory this definition should be added to `Makefile.common` because it's not yet a configured value, but as it may be the case that we want `tr` to be found by `configure`, it would seem more future-proof to me to define `TR` in `Makefile.build_config.in` close to `SED`. Then in the `Makefile you'll just have to use `$(SED)` and `$(TR)` rather than `sed` and `tr` to ensure that `LC_ALL` is properly defined when they are called. And then you may want to make these variables available to the shell script but I don't know if it's worth the trouble, except perhaps for sed because it may be a problem that the script does not use the sed that has been found by configure. Nothing to say about the third commit. And finally, regarding the last commit, here are a few notes about the commit message itself: I would write `interpreter` (with an e before the final r) rather than interpretor, but you may wnat to double check. It may also make the text more readable to mention the origin of the quoted text before the quoted text rather than after it. For instance: as stated by ... in .. and then you could even include the URL of the comment. Also, I was not completely sure whether the explanations should be in the commit or in the code itself but whatever you decide is fine, I jsut wanted to suggest this as food for thinking. And finally for the commit message: `Some reference` should be `Some references`, plural. Now that you know the PR number I think you can update `Changes`. And I think that's it for this round of review. :-) And thanks a gain for your cool work.

[shindere]

One other possible way to deal with the LC_* variables would be to add
something like this e.g. to Makefile.comon:

# Avoid funny character set dependencies
unexport LC_ALL
LC_COLLATE=C
LC_NUMERIC=C
export LC_COLLATE LC_NUMERIC

(borrowed from the Makefile of the Linux kernel so I guess it's safe to use)

[xavierleroy]

I've retained some of the changes I made to the Makefile, because I think they're easier to understand than the current version.

Could you please remove those changes? Three reasons:
1- these changes are orthogonal to the purpose of this PR, namely modernizing the C code of the runtime system;
2- these changes are problematic, as @shindere outlined;
3- there's too much churn in Makefiles right now, so let's not change something that is not broken, merely hard to read.

Without those Makefile changes I'll be happy to approve and merge this PR.

[shindere]

Xavier Leroy (2023/01/11 08:40 -0800):

3- there's too much churn in Makefiles right now, so let's not change something that is not broken, merely hard to read.

Isn't this a bit contradictory with #11844? ;-)

[xavierleroy]

Isn't this a bit contradictory with #11844? ;-)

Well, there's a budget for Makefile churn, and I'm happier to spend it on #11844 than on this PR. Plus, I'm pretty sure #11844 doesn't change the build itself, just what is displayed during the build, while I'm less sure here.

[MisterDA]

Thank you @shindere for the nice review, I've added your suggestions for the commit message. I like to keep longer comments and references in the commit message as not to add too much info in the code.

Following Xavier's message I've removed the commits touching the Makefile from this PR. Someone might want to revisit the idea later.

This might be good to go now?

[gasche]

I'm in a merging mood right now so I decided to interpret the following words of Xavier

Without those Makefile changes I'll be happy to approve and merge this PR.

as saying that I can approve on his behalf now that the changes he requested have been performed.