Grammar and other issues in the rules

[xexyl]

(I will do a similar discussion for the guidelines - I hope to do that later today.)

I am not sure how you wish to deal with this. I can certainly do a pull request and rebuild them. Or you can fix them, Landon, if you choose. Here are some of the issues.

rules

Top of the rules

See the FAQ on “obtaining and compiling the mkiocccentry tools” and the FAQ on “how to enter the IOCCC” as that FAQ has import details on how to register as well as how to upload your submission for the IOCCC.

It should be 'important', not 'import'.

NOTE: this is also in rule 3!

Rule 3

While the contest is open, you may modify your previously uploaded submission by rebuilding your submission with the mkiocccentry(1) tool and then re-uploading it to the same slot no the submit server.

'no' should really be 'number' to be more clear.

See also above where an earlier comment in the rules is also in rule 3.

Rule 15:

The judges are not responsible for delays in email, please plan enough time for one automated exchange of email as part of your submission.

It's no longer a single email exchange so it might want to be updated?

Rule 17

Each above mentioned tools has a -h option that provides command line help. For additional details, see the tools’ man pages and the guidelines.

This is almost certainly my fault but it would be better to be something like...

Each above mentioned tool has a -h option that provides command line help. For additional details of each tool, see its man page, and in some cases, the IOCCC guidelines.

In particular, username is in the form of: xxxxxxxx-xxxx-4xxx-axxx-xxxxxxxxxxxx where x is a hexadecimal digit in the range [0-9a-f]. And yes, there is a 4 (UUID version 4) and an a (UUID variant 1) in there.

This is also my fault. I did not remember that this format was in the rules when I fixed it to be a bit less strict at your request.

The .info.json must be valid JSON and pass the chkentry(1) tests. It is generated by the mkiocccentry(1) tool.

The .auth.json must be valid JSON and pass the chkentry(1) tests. It is generated by the mkiocccentry(1) tool.

This could be ambiguous. It could be better to have the last sentence as:

The .info.json file is generated by ...
The .auth.json file is generated by ...

Next one also in this rule.

You submission may have additional files, however the filenames of those additional files MUST:

• Be less than 100 characters in length.
• Match the regular expression: ^[0-9A-Za-z][0-9A-Za-z._+-]*$

The mkiocccentry(1) tool will not package any files that do not meet those requirements.

This last part does not seem to be true: in particular the first one: 100 characters in length for filenames.

It might also be good to mention that txzchk does this check (well the second one: the first one not but if we added it to a new function that tests filename it might be easy enough to do). This might delay things a bit so it could be that the rule suggests it but not say it is enforced. I'm not sure. It's also possible I forgot something but it seems not.

In fact there are only two cases in txzchk.c that use strlen() and neither are for that purpose! The variable name in the file filename also does not suggest it's being tested (in that way). It does check the POSIX safe + chars though.

Either way the statement about the length of the filename seems to not be true!

Your entry may NOT have subdirectories. However, you can provide files that are in different directories as mkiocccentry(1) will copy them to the work directory (see the guidelines for more details).

It would be clearer to state that one may specify files they have in other directories in their system. One would like to believe it is clear enough but it might be ambiguous to some .. maybe.

Filenames in your entry (that is, not including the files generated by the mkiocccentry(1) tool or the tools it or any other tool invokes) MUST:

Be less than 100 characters in length

As above this seems to not be true, at least not in the code.

NOT have a / (excluding the entry directory that the mkiocccentry(1) tool generates).

This is checked in txzchk.c yes.

NOT contain a path component of: . (that is, with the exception of files generated by mkiocccentry(1) itself, it must have NO .).

This is also checked.

NOT contain a path component of: .. (that is, NO ..).

Right - checked also.

Match the regular expression ^[0-9A-Za-z][0-9A-Za-z._+-]*$ (again, excluding files generated by mkiocccentry(1)).

Also checked. However to help simplify the rule it might be good if we merge the previous part of the rule that mentions only two of these (including one that seems to not be true) into this list so as to not only make it shorter but to also be slightly less confusing.

The txzchk(1) tool will verify these (and other things) for you and the chkentry(1) tool will do additional checks on the contents of the .auth.json and .info.json files (including JSON validity). If these checks fail it is an error and mkiocccentry(1) will fail. In this case it is very possibly a bug; please report it as a bug at the mkiocccentry issues page.

.. except for the 100 length of filename of course .. unless I'm missing some trick macro. In fact I don't even see 100 by itself in soup/limit_ioccc.h!

This means you should MAKE SURE that you use mkiocccentry(1) to package your submission; mkiocccentry(1) will run the above mentioned tools (that do not act on the tarball) before creating the tarball and after the tarball is created it will then verify that the tarball is okay by running txzchk(1) on it. If any step fails it is an error and submitting the submission will result in violating this rule.

I believe that I wrote this but whether or no it might be good, if we're being thorough, to say that chkentry is run on the two JSON files prior to the tarball being formed, and that the tarball MUST have them!

End part of rules

You should be sure you have the current IOCCC rules and IOCCC guidelines prior to submitting entries.

Okay it might be unnecessary here but ... one does not need to have them: rather they should read them.

Also it uses the wrong term 'entries'.

[lcn2]

All good points, @xexyl

Please prepare separate issues for each tool to be fixed. Feel free to open separate PRs for each rule to be fixed under those separate issues.

[xexyl]

All good points, @xexyl

Please prepare separate issues for each tool to be fixed. Feel free to open separate PRs for each rule to be fixed under those separate issues.

So .. open a new issue at mkiocccentry for both txzchk and mkiocccentry not restricting a filename size? Alternatively I could just fix it. Though if it has to be in chkentry too I could add a new function and maybe add a call to it in chkentry.

What do you prefer of these options?

[lcn2]

All good points, @xexyl

Please prepare separate issues for each tool to be fixed. Feel free to open separate PRs for each rule to be fixed under those separate issues.

So .. open a new issue at mkiocccentry for both txzchk and mkiocccentry not restricting a filename size? Alternatively I could just fix it. Though if it has to be in chkentry too I could add a new function and maybe add a call to it in chkentry.

What do you prefer of these options?

We doubt we would ever want a filename of an unlimited size, let alone hundreds of bytes.

No, we don't want someone to create a filename 100k bytes long and use the long filename as their source.

A number of file systems cannot handle huge filenames, and such a winning entry inventory would be obnoxious.

Nevertheless if you open an issue as an enhancement, such matters could be discussed.

Such an issue would be an enhancement request. So if you do consider such an enhancement, put it is terms of changing the filename size instead of just removing the filename length restriction.

[xexyl]

All good points, @xexyl

Please prepare separate issues for each tool to be fixed. Feel free to open separate PRs for each rule to be fixed under those separate issues.

So .. open a new issue at mkiocccentry for both txzchk and mkiocccentry not restricting a filename size? Alternatively I could just fix it. Though if it has to be in chkentry too I could add a new function and maybe add a call to it in chkentry.
What do you prefer of these options?

We doubt we would ever want a filename of an unlimited size, let alone hundreds of bytes.

Me too.

No, we don't want someone to create a filename 100k bytes long and use the long filename as their source.

Agreed.

A number of file systems cannot handle huge filenames, and such a winning entry inventory would be obnoxious.

Yes. And iirc POSIX has a limit too. Plus the max arg length is something to consider as well.

Nevertheless if you open an issue as an enhancement, such matters could be discussed.

Such an issue would be an enhancement request. So if you do consider such an enhancement, put it is terms of changing the filename size instead of just removing the filename length restriction.

Oh I already made it a bug report. And I know that some file systems cannot manage that and I agree with your reasoning.

But I wasn't suggesting to remove the filename restriction as such. I was saying that if we needed to it could be a recommendation this time round and then the code could be fixed. However given that it's pending for a month or so there is no need for that.

You suggest enhancement though .. does that mean it is not technically a bug? It seems more like a bug to me since it doesn't follow the rule. Anyway if you think it's more of an enhancement feel free to change the tag (or whatever they call it) and title. We can then discuss the details.

[xexyl]

Okay I'll open an issue for each in a bit (I hope): that way things can be discussed as I have a number of questions and this seems like it's kind of OT here.

[xexyl]

.. actually I see it's more complicated than that :( some functions check for 0 length and others have no check. So it seems this will take a bit of work. I don't have the time right now to open an issue. I might have to do that tomorrow. Unsure of this for the moment. It's an unfortunate problem but I'm glad I discovered it.

[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.

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again.