Recommend compiler settings.

[SirWumpus]

Guideline question about compiler settings:

   -std=gnu17 -O3 -g3 -Wall -Wextra -pedantic

• This still appears to be GNU CC centric? Is there a Clang version?
• Why is it not -std=c17

• For GNU, some feature defines should probably be set. Example:

  Frack gcc needs extra #define to enable SUS standard strdup(), strndup().

  GCCCPP := -D_XOPEN_SOURCE=700

See Feature Test Macros or man 7 feature_test_macros.

Maybe special Rule 2b exceptions for IOCCC portability:

   #define _XOPEN_SOURCE 700

Counts as zero (0) octets? But having that in the source is unsightly. Compiler option probably best.

[xexyl]

Clang actually supports that. That would explain that part anyway. I would not mind the other part though a -D also takes care of it.

[xexyl]

And yes it's better indeed on the compiler for the reason you cited.

[lcn2]

Thanks for the feedback @SirWumpus

The gnu17 is widely supported by non-gnu compilers including clang. Use of gnu17 over gcc17 will be advantageous for most entries.

The Rule 2a/Rule 2b have already been proposed to expand over there levels under IOCCC27.

Given the feedback we received when the draft next rules and guidelines were released, we doubt there is any appetite for expanding them further, let along a complex Rule modification of the form: "if do this the it counts at X bytes".

The expansion of the Rule 2a/Rule 2b is not without controversy. The effort to keep it in the set for IOCCC28 is non-zero. Presuming it stays in (and there is a reasonable hope it will stay in) for IOCCC28, the effects on the contest (the impact on the quality of submissions) will need to be assessed (I.e., over a contest or 2) before we would do any more fine tuning. Unless the proposed Rule changes cause us problems, we would not anticipate a Rule 2 change for IOCCC29.

BTW: This probably should have been opened as a discussion in the other repo (currently temp-test-ioccc. This repo is just for tools that implement the IOCCC rules and consider IOCCC guidelines. Nevertheless we believe this answer is a sufficient response and so with respect we will close this issue.

[xexyl]

The expansion of the Rule 2a/Rule 2b is not without controversy. The effort to keep it in the set for IOCCC28 is non-zero. Presuming it stays in (and there is a reasonable hope it will stay in) for IOCCC28, the effects on the contest (the impact on the quality of submissions) will need to be assessed (I.e., over a contest or 2) before we would do any more fine tuning. Unless the proposed Rule changes cause us problems, we would not anticipate a Rule 2 change for IOCCC29.

I hope that by this you will not penalise submissions (less chance of winning, in other words), if they use the tighter restrictions .. since although rules do change the size limit has been consistent for years and the contest hasn't happened in years but that's the perfect time for others to work on submissions.

I might add that I was very surprised at the increase and I am also mixed on it. I think it might ultimately lead to even more feature rich programs (of course it will) but at the same time it's also more impressive (another important point) when so much is put in fewer bytes. It's also one of the things that impressed me more with games in previous eras: limited hardware and yet so much was done (and a lot of it incredible) where now we have so much more powerful hardware without nearly as many limitations (there are other things too that I don't like as much though I can't judge now as it's now been too long since I've played any but even so it's far less impressive what they have now).

Well I'm sure you'll think about it all but I did want to say that in the probably unlikely case it wasn't considered.