Grammar and other issues in the guidelines

[xexyl]

Like the rules discussion here is one for the guidelines.

We do realize that there are holes in the rules, and invite entries to attempt to exploit them. We will award ‘Worst abuse of the rules’ or ‘Best abuse of the rules’ or some variation and then plug the hole next year.

Not a big deal but 'entries' is used again here, rather than 'submissions'.

When ‘;’, ‘{’ or ‘}’ are within a C string, they may still not be counted by the IOCCC size tool. This is a feature, not a bug!

Okay well this could be clearer too, maybe, particularly w its 'may still not be' .. but since it's been there for ages (even if somewhat modified) I won't get into it. Still mentioning it in case. Perhaps it's meant to be a bit ambiguous but either way it could be interpreted more than one way.

To help you with editing a submission, the mkiocccentry(1) tool has some options to write OR read from an answers file so you do not have to input the information about the author(s) and the submission more than once (unless of course you need to make some changes, in which case you can use the option that overwrites the file).

Although right under that is the FAQ on the tool.. maybe it should briefly mention the respective options? Though it might (not sure) be later in the guidelines. But even if it is later in the guidelines maybe it belongs here instead? Again I don't know.

Because txzchk(1) tool uses fnamchk(1) tool as part of its algorithm, mkiocccentry(1) does not directly invoke fnamchk(1), although we will in the judging process.

I forgot the word 'the' before txzchk(1). I know that probably bothers nobody but me but still.

IMPORTANT NOTE: The use of -std=gnu17 does NOT imply the use of the gcc compiler! We often start by compiling using the clang C compiler instead.

The markdown has gcc in a code block and clang in bold.

Your source code, post-pre-processing, should not exceed the size of Microsoft Windows. :-)

Other windows, on the other hand, might be OK: especially where “X marks the spot”. Yet on the third hand, windows are best when they are “unseen” (i.e., not dirty). :-)
We do not recommend submitting systemd source code to the IOCCC, if nothing else because that code is likely to exceed the source code size limit. This isn’t to say that another highly compact and obfuscated replacement of init would not be an interesting submission.

I'm pretty sure I added the MS Windows one as a joke and you added to it. Also it is not mentioned in the 2019 guidelines: In which case the change mark is missing.

And although the systemd one is old it always makes me laugh too and I appreciate that!

There are more than 1 typos in this very sentence.

.. and this is one of the reasons I have tried to somewhat limit what I've said .. though I know I failed that miserably :-)

X client entries should be as portable as possible. Submissions that adapt to a wide collection of environments will be favored. For example, don’t depend on a particular type or size of display. Don’t assume the use of a particular browser. Instead assume a generic browser that forms to a widely used W3C standard. Don’t assume a particular sound sub-system or video driver is installed in the OS. Instead, make use of a well known and widely available open source program (one that actually works) to display audio/visual data.

Hmm ... browser with X?

X client entries should avoid using X related libraries and software that are not in wide spread use.

... but do you wish to modify this to say it might be good to use wayland instead: since X is now deprecated?

Try to avoid entries that play music that some people believe is copyrighted music.

Fun fact: some years ago the ridiculous copyright of 'Happy Birthday' was finally struck down.

Rule 13 states any C source that fails to compile because of unescaped octets with the high bit set (octet value >= 128) might be rejected. Instead of unescaped octets, you should use or escapes:

'you should use or escapes'?

Anyone can format their code into a dense blob. A really clever author will try format their submission using a “normal” formatting style such that at first glance (if you squint and don’t look at the details) the code might pass for non-obfuscated C. Deceptive comments, and misleading formatting, in some cases, may be a plus. On the other hand, a misleading code style requires more source bytes.

... 'try to' or 'try and'?

If IOCCC judges are feeling ornery we might choose to compile your program for running on an Arduino or a PDP-11. Heck, should we ever find an emulator of 60-bit CDC Cyber CPU, we might just try your submission on that emulator as well :-)

'If the IOCCC'? Okay this is another example where it does not matter but since you mentioned somewhere you hope you did not make typos ... (though this is an old one)

Moreover the might try to also factor 3.5 or 0x7, or Fred, so you want to might state:

Probably should be 'they might' :-)

Do not fear if you’re not 100% sure of the significance of 2305567963945518424753102147331756070 as it is not of prime importance: or is it? :-)

Of course it is :-) (okay no corrections here)

We don’t mind the use ASCII tab characters in your C code. Feel free to use ASCII tab characters if that suits your obfuscation needs. If is perfectly OK to use tab characters elsewhere in your submission, just not in markdown files as this tends complicate and annoy us when it comes time to rendering your markdown content.

Should be 'IT is perfectly OK ...'.

PLEASE observe our IOCCC markdown guidelines when forming your submission’s remarks.md file. And if your submission contains additional markdown files, please follow those same guidelines for those files. See also Rule 19 and our FAQ on “markdown”.

This should also link to the markdowns guideline page.

We RECOMMEND you put a reasonable amount effort into the content of the remarks.md file: it is a required for a reason. :-)

... 'of effort'.

Legal abuse of the IOCCC rules is NOT an invitation to violate the IOCCC rules. A submission that violates the rules in the opinion of the judges, WILL be disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK! If you have a submission that might otherwise be interesting, you might want to submit two versions; one that does not abuse the IOCCC rules and one that does.

Probably a colon would be better instead of a semicolon in the last part. But it probably doesn't matter either.

We are often asked why the contest IOCCC rules and IOCCC guidelines seem too strange or contain mistakes, flaws or grammatical errors. One reason is that we sometimes make genuine mistakes. But in many cases such problems, flaws or areas of confusion are deliberate.

:-)

requirements from marketing, sales, product management an even from customers themselves on a all too regular basis.

AND even ....

on the iocccsize tool

Perhaps it should be mentioned that now it's the mkiocccentry that uses the code? As in that you might not run it directly? It might help simplify the guidelines too (though maybe not).

Other things

There are other places where 'entries'/'entry' is used instead of 'submissions'/'submission'. This probably doesn't matter but to ever so slightly shorten this I decided to not include them.

It has been shown that receiving anonymous gifts provides the IOCCC judges with a nice dopamine boost, and happy IOCCC judges help make the IOCCC better for everyone. :-)

... are you sure you want a dopamine boost ? :-)

One other thing...

I've deliberately omitted one that I don't want to get into .. unless you want me to :-) .. and then I might .. or not :-)

Okay actually I omitted more than one.

Another one more one other thing...

For those who wonder (or who like to ponder):

Default optimisation level

You may change the level of optimization and compiler debug level that your submission is compiled with, by modifying the OPT Makefile variable. For example, to compile without optimization, and to include debug symbols:

... might not an issue because more than one person wrote it. And although macOS does not know it, the Z instead of the S is actually valid in British English, even though it's not the usual spelling. On the other hand it might be argued it would be better to synchronise it: or should it be? It is after all obfuscated :-)

[lcn2]

You rise valid points @xexyl in your GH-discussions/32 initial comment.

Perhaps there needs to be an issue opened and then PRs under that issue to fix or improve many of the matters you raised?

[xexyl]

You rise valid points @xexyl in your GH-discussions/32 initial comment.

Perhaps there needs to be an issue opened and then PRs under that issue to fix or improve many of the matters you raised?

An issue so it can be discussed first, I presume? Otherwise I could just fix them.

[lcn2]

You rise valid points @xexyl in your GH-discussions/32 initial comment.

Perhaps there needs to be an issue opened and then PRs under that issue to fix or improve many of the matters you raised?

An issue so it can be discussed first, I presume? Otherwise I could just fix them.

OK, just issue a PR to fix them. Thanks @xexyl

[xexyl]

You rise valid points @xexyl in your GH-discussions/32 initial comment.

Perhaps there needs to be an issue opened and then PRs under that issue to fix or improve many of the matters you raised?

An issue so it can be discussed first, I presume? Otherwise I could just fix them.

OK, just issue a PR to fix them. Thanks @xexyl

Well I already opened an issue (as I see you see now) so we can discuss things. I think in some cases it is definitely useful as it will make things easier to parse but in other cases it's less important.

[lcn2]

For those who might have wondered into this discussion:

Please see issue #33 and update related to work on a number of the topics discussed above.