Enhancement: Compile all winners on modern systems

[lcn2]

Scope - About this issue

Attempt to fix, where possible, the Makefiles so that most entries can be compiled on a reasonable number of modern systems. This is NOT possible for all entries.

NOTE: This writeup is subject to changes and revisions as the understanding of this issue evolves / improves. Check back to this note from time to time. When modification are made to this comment, we will try to add a note indicating that the scope of this issue has been updated.

This is not simply about bug fixing entires

If the bug is trivial to fix, and does not impact the look and feel of the entry, the a fix is probably just fine. But try to resist the urge to fix all bugs.

For example. in cases where the use of gets() causes an annoying message when the entry is run that spoils the entry or even prevents it from working as original intended, then replacing the call with fgets() is a good thing to do.

If the bug would make it hard for someone to learn something about C, or even to be amused with what can be come with C: then the bug should be fixed. If the bug is annoying and makes it hard for someone to appreciate the entry, or learn about some subtile aspect of C, then the bug should be fixed.

If a bug is to documented in README.md and offered as a challenge to the the reader to fix, that is fine too. And if such a bug / feature is documented in README.md as a challenge, then it probably should be mentioned in the bugs.md as a "INABIAF: It's not a bug it's a feature" status. This sort of challenge should be reserved for those programs for which the bug does not "make it hard for someone to learn".

If the bug is very hard to fix, consider documenting it in bugs.md and ask for people to try and fix it. In this case the "INABIAF: It's not a bug it's a feature" status should NOT be used. Instead the "STATUS: known bug - please help us fix" should be used.

There is no hard rule for when to fix code. It is a judgement call.

When the Makefile of a winner needs to be modified

It is fine to modify the winner Makefile, such as adding things to the compile line, in order to allow an entry to compile under a modern system.

The individual Makefiles in the winning entry directory do NOT need to be preserved. Nevertheless the style and format of ALL Makefiles in winner directories should be reasonable consistent such that is one wanted to make a global change across all winner Makefiles, one could do so with a reasonable set of command lines.

On year level Makefiles

In some cases, the given year's original YYYY/Makefile was renamed to YYYY/orig.Makefile. This file is preserved for historical purposes AND in some cases may give a hint as to how the original published winner was to be compiled. Such information may be a useful clue as to the compile process when the winners were first published.

In some years, the style was to have all of the winners in a single directory. This has been changed so that each winner is in its own individual directory under the year directory.

In some years, there were both "YYYY/ansi.mk" and "YYYY/common.mk" makefiles under the year directory (instead a single Makefile). These makefiles have been renamed to YYYY/orig.ansi.mk and YYYY/orig.common.mk and serve a similar function as the above mentioned YYYY/orig.Makefile.

When the source needs to be modified

Where the source of a winner must be changed, and there is NOT already an original source file, preserve the winning code by coping it into another file. For example, prog.c would be copied into prog.orig.c (assuming such a file does not already exist) BEFORE modifying the source. Reference the original source as an alternate executable in the Makefile.

See 1987 lievaart or 1987 heckbert for examples of how to do this.

When the source had to be modified, the winner Makefile should issue an echo with a caution. For example:

${PROG}.orig: ${PROG}.orig.c
        @echo "NOTE: The original source may not compile using modern compilers."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

When an entry cannot be compiled

Some entries are just too difficult to update to compile. That is OK.

When this happens, the winner Makefile should be modified to echo this is the case. For example:

${PROG}: ${PROG}.c
        @echo "NOTE: This entry uses non-standard args to main() that do not work with modern compilers."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

Or for example:

${PROG}: ${PROG}.c
        @echo "NOTE: This entry requires a non-standard K&R C compiler to compile."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

Or for example:

${PROG}.orig: ${PROG}.orig.c
        @echo "NOTE: The original source may not compile using modern compilers."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

Probability

Making a winner compile on all possible systems is out of scope for this issue.

The intent is to try to compile entires on reasonably modern Unix / Linux based systems.

[xexyl]

About this issue. I know I told you once but it was quite a while back and we have done a lot since then (and had a lot of laughs together as well, storytelling and other things) but Yusuke Endoh has actually done this. We could use a lot of what he's done (crediting him of course where it would be good to do so if there's a way to do it):

https://mame-github-io.translate.goog/ioccc-ja-spoilers/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB&_x_tr_pto=wapp

Now as far as my comments on some of the below:

Scope - About this issue

Attempt to fix, where possible, the Makefiles so that most entries can be compiled on a reasonable number of modern systems. This is NOT possible for all entries.

The Makefile being fixed is one way that seems very reasonable.

NOTE: This writeup is subject to changes and revisions as the understanding of this issue evolves / improves. Check back to this note from time to time. When modification are made to this comment, we will try to add a note indicating that the scope of this issue has been updated.

Thank you for this note - I might have missed it otherwise.

Do NOT try to bug fix entires

While getting the program to run properly is beyond the scope of this Enhancement issue, a minor amount of checking that the program runs may be in order. In such cases, one should look at the "judges remarks / winner writeup / winner's remarks" for hints as to how to do this.

There is one case where I don't want to address it and this is going to sound kind of funny but: the famous one by Korn .. I never did get a chance to see if I can figure it out because always I've been so tired. However I still want to try it one day and I don't want to have a spoiler with it.

But that being said I can certainly look at the other issues. And who knows, maybe when doing it I'll be in the right mindset to look at that entry too.

Nevertheless:

This is NOT AN ISSUE TO FIX BUGS in winning entries

I'm glad you stated that because I can see how some might interpret getting to compile == fixing bugs.

Where is it obvious that a compiled program, when run according to the "judges remarks / winner writeup / winner's remarks" file(s), a warning should be added to the winner's Makefile. For example:

${PROG}: ${PROG}.c
        @echo "NOTE: This entry is likely to fail and/or dump core on modern computers"
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

That sounds like a good idea to me.

When the Makefile of a winner needs to be modified

It is fine to modify the winner Makefile, such as adding things to the compile line, in order to allow an entry to compile under a modern system.

As above.

The individual Makefiles in the winning entry directory do NOT need to be preserved. Nevertheless the style and format of ALL Makefiles in winner directories should be reasonable consistent such that is one wanted to make a global change across all winner Makefiles, one could do so with a reasonable set of command lines.

Plus comments might be useful too. But something that I wonder about.

We know that 2020 entries will compile on modern systems so we need not touch them. I guess we can still try it though.

I actually am aware of a segfault in one winning entry in recent years but I'm not sure if it's a bug or not. In any event I personally don't even feel right trying to fix it: it would be kind of a breach in my mind because it would kind of make it less like the winner's. Still there's something to be said about making them work if possible. See below for another thought.

On year level Makefiles

In some cases, the given year's original YYYY/Makefile was renamed to YYYY/orig.Makefile. This file is preserved for historical purposes AND in some cases may give a hint as to how the original published winner was to be compiled. Such information may be a useful clue as to the compile process when the winners were first published.

That's interesting. Maybe I won't need it but perhaps you could elaborate a bit on this? The historical purposes I mean. Though the fact you renamed them means maybe I don't need to touch them except that they might give a clue as to how to get it to work (in some cases).

In some years, the style was to have all of the winners in a single directory. This has been changed so that each winner is in its own individual directory under the year directory.

I'm glad you changed that indeed.

In some years, there were both "YYYY/ansi.mk" and "YYYY/common.mk" makefiles under the year directory (instead a single Makefile). These makefiles have been renamed to YYYY/orig.ansi.mk and YYYY/orig.common.mk and serve a similar function as the above mentioned YYYY/orig.Makefile.

Sounds like a good idea that you renamed them yes.

When the source needs to be modified

Where the source of a winner must be changed, and there is NOT already an original source file, preserve the winning code by coping it into another file. For example, prog.c would be copied into prog.orig.c (assuming such a file does not already exist) BEFORE modifying the source. Reference the original source as an alternate executable in the Makefile.

This is what I was thinking about and referring to above: there's an equal argument for making the working copy a different name and just having the compiler name it the correct name. In other words the Makefile would compile the fixed copy but write (as in -o) to the name expected. What do you think of that? If so what would think it could be called?

At the same time there's an argument for making it orig also. There's a problem however: what about entries that already have this file? Then what should it be called?

See 1987 lievaart or 1987 heckbert for examples of how to do this.

When the source had to be modified, the winner Makefile should issue an echo with a caution. For example:

${PROG}.orig: ${PROG}.orig.c
        @echo "NOTE: The original source may not compile using modern compilers."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

Okay well that's certainly another way to go about it but still what if an entry cannot be compiled but already has an .orig.c file ? That would be another reason to make the fixed copy in something like .fixed.c (or whatever).

When an entry cannot be compiled

Some entries are just too difficult to update to compile. That is OK.

I believe the link I gave above might have solved it all but I don't know.

When this happens, the winner Makefile should be modified to echo this is the case. For example:

${PROG}: ${PROG}.c
        @echo "NOTE: This entry uses non-standard args to main() that do not work with modern compilers."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

Or for example:

${PROG}: ${PROG}.c
        @echo "NOTE: This entry requires a non-standard K&R C compiler to compile."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

Or for example:

${PROG}.orig: ${PROG}.orig.c
        @echo "NOTE: The original source may not compile using modern compilers."
        ${CC} ${CFLAGS} $< -o $@ ${LIBS}

Good idea!

Probability

Making a winner compile on all possible systems is out of scope for this issue.

The intent is to try to compile entires on reasonably modern Unix / Linux based systems.

I'm glad you said that as well though I hope that it's probable that we can get most of them to work / port them to modern systems ... :-)

[lcn2]

There is one case where I don't want to address it and this is going to sound kind of funny but: the famous one by Korn .. I never did get a chance to see if I can figure it out because always I've been so tired. However I still want to try it one day and I don't want to have a spoiler with it.

For a few select entries such as 1987/korn, we can process the README.md if you prefer.

[xexyl]

There is one case where I don't want to address it and this is going to sound kind of funny but: the famous one by Korn .. I never did get a chance to see if I can figure it out because always I've been so tired. However I still want to try it one day and I don't want to have a spoiler with it.

For a few select entries such as 1987/korn, we can process the README.md if you prefer.

Yes please! That would be appreciated. Thank you.

[lcn2]

That's interesting. Maybe I won't need it but perhaps you could elaborate a bit on this? The historical purposes I mean. Though the fact you renamed them means maybe I don't need to touch them except that they might give a clue as to how to get it to work (in some cases).

Sometimes we found that we needed to look back a the original Makefile in order to figure our or even fix how we built an entry. This can be especially true for entries where the build procedure is rather complex.

Yes, the "original" files, be they source (even source that doesn't compile) and original Makefiles can be left as they are.

[xexyl]

That's interesting. Maybe I won't need it but perhaps you could elaborate a bit on this? The historical purposes I mean. Though the fact you renamed them means maybe I don't need to touch them except that they might give a clue as to how to get it to work (in some cases).

Sometimes we found that we needed to look back a the original Makefile in order to figure our or even fix how we built an entry. This can be especially true for entries where the build procedure is rather complex.

Of course. And with the IOCCC it should be! :-) Well okay maybe not but it IS ironic that a build procedure is complicated for the IOCCC. Or maybe it's not ironic! :-)

Yes, the "original" files, be they source (even source that doesn't compile) and original Makefiles can be left as they are.

So...the ones that can be fixed: how do we name them then? Or do you mean the contents of them (which makes sense)?

[lcn2]

This is what I was thinking about and referring to above: there's an equal argument for making the working copy a different name and just having the compiler name it the correct name. In other words the Makefile would compile the fixed copy but write (as in -o) to the name expected. What do you think of that? If so what would think it could be called?

Something like that can work. So long as the primary source file is, say, prog.c that can work.

However for an entry that includes itself via some #include stuff...and...stuff you may be better off dong a copy of prog.c to the original source filename.

It will all depend on the entry of course.

[xexyl]

This is what I was thinking about and referring to above: there's an equal argument for making the working copy a different name and just having the compiler name it the correct name. In other words the Makefile would compile the fixed copy but write (as in -o) to the name expected. What do you think of that? If so what would think it could be called?

Something like that can work. So long as the primary source file is, say, prog.c that can work.

I think it might be better the way I suggested. I haven't given it a great deal of thought but it would certainly also make it so that if an entry already has an orig version would not be a problem with it, rare though that might be.

Same goes with alt as some entries have that too.

However for an entry that includes itself via some #include stuff...and...stuff you may be better off dong a copy of prog.c to the original source filename.

That's also a concern of mine esp with entries that don't easily compile (to test).

It will all depend on the entry of course.

Of course!

[lcn2]

Yes, the "original" files, be they source (even source that doesn't compile) and original Makefiles can be left as they are.

So...the ones that can be fixed: how do we name them then? Or do you mean the contents of them (which makes sense)?

The convention is that the original filename for something like prog.c is prog.orig.c.

The convention is that the original binary for something like prog is prog.orig.

The convention is that the original Makefile for something like Makefile is Makefile.orig.

[xexyl]

First I'm glad you got a laugh out of my comment above.

Yes, the "original" files, be they source (even source that doesn't compile) and original Makefiles can be left as they are.

So...the ones that can be fixed: how do we name them then? Or do you mean the contents of them (which makes sense)?

The convention is that the original filename for something like prog.c is prog.orig.c.

The convention is that the original binary for something like prog is prog.orig.

The convention is that the original Makefile for something like Makefile is Makefile.orig.

That's true but what if the entry that needs fixing already has a prog.orig.c ? It could happen.

[lcn2]

At the same time there's an argument for making it orig also. There's a problem however: what about entries that already have this file? Then what should it be called?

Is there is a prog.orig.c, assume it is original. In this case it is the program source that was originally submitted. If there a a prog.c, that too is original. So you one needs to modify the source, it would be copied to prog.orig.c to preserve it.

BTW: Later on, when an author does a pull request to modify their code for some reason, we will "clone" a copy of that source from the base submit. The original source that won is always preserved and made directly available as a file.

[xexyl]

At the same time there's an argument for making it orig also. There's a problem however: what about entries that already have this file? Then what should it be called?

Is there is a prog.orig.c, assume it is original. In this case it is the program source that was originally submitted. If there a a prog.c, that too is original. So you one needs to modify the source, it would be copied to prog.orig.c to preserve it.

Perhaps I am not wording it well enough. Let me try again.

Let's say the following holds:

• an entry does not compile or needs to be modified in some way
• this same entry already has a prog.orig.c

What do we do in this case? That's something that naming it based on it being fixed would be useful with. But on the other hand it makes sense to name it as orig also. I'm mixed on this but either way there is a possibility that the file might already exist so what should be done then ?

BTW: Later on, when an author does a pull request to modify their code for some reason, we will "clone" a copy of that source from the base submit. The original source that won is always preserved and made directly available as a file.

That's good it'll always be available. How do you mean. you'll clone it? Not their fork ?

[xexyl]

BTW: I tried to clone this repo but it wants to fork the winner one (which I already did as you know), not this one.

This seems like a possible problem. Is it? If so what do you want me to do?

[lcn2]

BTW: The links in the years.html file will need to be maintained (see issue #3) as files are renamed, copied or removed.

Until issue #4 is completed and the links in years.html can be automatically built by some tool, they will have to be maintained by hand. Sorry (tm Canada 🇨🇦), we know that is an extra step for file adds, moved and removals. But automating this requires issue #3 and issue #4 to be completed.

[lcn2]

BTW: I tried to clone this repo but it wants to fork the winner one (which I already did as you know), not this one.

This seems like a possible problem. Is it? If so what do you want me to do?

Humm ... do we need to wipe out this repo and upload a brand new one in order to clone it? Is there a FAQ or discussion about cloning a clone?

[xexyl]

BTW: The links in the years.html file will need to be maintained (see issue #3) as files are renamed, copied or removed.

Thanks for the reminder. A BTW from me.

BTW: are these the updates you were thinking of in the 'questions' thread in the other repo ?

Until issue #4 is completed and the links in years.html can be automatically built by some tool, they will have to be maintained by hand. Sorry (tm Canada 🇨🇦), we know that is an extra step for file adds, moved and removals. But automating this requires issue #3 and issue #4 to be completed.

Would it be better to work on those first then?

[xexyl]

BTW: I tried to clone this repo but it wants to fork the winner one (which I already did as you know), not this one.
This seems like a possible problem. Is it? If so what do you want me to do?

Humm ... do we need to wipe out this repo and upload a brand new one in order to clone it? Is there a FAQ or discussion about cloning a clone?

I have no answer to either question. If you do have to wipe it though that's unfortunate because there's a lot of good discussion here already which would be lost :(

[lcn2]

Let's say the following holds:

an entry does not compile or needs to be modified in some way
this same entry already has a prog.orig.c

What do we do in this case?

Leave the prog.orig.c file alone because that is the original.

Modify prog.c as needed.

[xexyl]

Let's say the following holds:
an entry does not compile or needs to be modified in some way
this same entry already has a prog.orig.c
What do we do in this case?

Leave the prog.orig.c file alone because that is the original.

Modify prog.c as needed.

Ahh... I see what you mean now. Okay. That does make sense then.

[xexyl]

BTW: I tried to clone this repo but it wants to fork the winner one (which I already did as you know), not this one.
This seems like a possible problem. Is it? If so what do you want me to do?

Humm ... do we need to wipe out this repo and upload a brand new one in order to clone it? Is there a FAQ or discussion about cloning a clone?

I have no answer to either question. If you do have to wipe it though that's unfortunate because there's a lot of good discussion here already which would be lost :(

Also I see this on the repo:

This branch is 58 commits ahead, 12 commits behind ioccc-src:master.

So maybe you do need to start it over .. not sure but it's unfortunate. If you do I recommend that you keep this repo open and we can discuss it here. Then when each one is resolved it can be closed. Future issues could be opened in the other one - or here so that we don't mix up issue numbers.

Yet another repo would also mean we would not be able to link to commits as easily either.

[lcn2]

That's good it'll always be available. How do you mean. you'll clone it? Not their fork ?

Assume some time in the future someone wishes to modify a prog.c and there is no prog.orig.c. Then before the pull request is processed, we will cp prog.c prog.orig.c and then git add prog.orig.c and then git commit ... and then git push.

If we make a mistake and forget and process the pull request before making prog.orig.c, we will simply git checkout the original pre-modified version of prog.c, copy it over to prog.orig.c, and restore the pull request modified prog.c.

Either way, we will need to modify the Makefile to handle the new prog.orig.c, perhaps with comments echoed by the Makefile. We will also need to modify the manifest of the .award.json file (see issue #4) as well.

Obviously a tool can be made to do the above so that it is less error prone.

[xexyl]

I figured out a way to redo this repo without losing the contents of the dialogue. If you keep this repo you can copy paste the issues (same number for each issue) and then link to the thread here so that we can reference anything. Then future comments can be done there.

But how to do it I don't know.

[lcn2]

... but what if the entry that needs fixing already has a prog.orig.c ? It could happen.

Yes, then prog.orig.c remains as the original source and the prog.c is modified.

As IOCCC judges we do this when judging an entry and we see a trivial fix to "rescue" a submission. That is where the current set of prog.orig.c came from.

[xexyl]

With the exception of 1989/westley which I have pending changes (at least in how to try it) and which is also more complicated and thus will take more time and those which are not supposed to compile (1994/westley) and finally those with architectural limitations everything compiles in macOS and linux! For macOS obviously just clang and for linux both gcc and clang!

I will either fix the issue with the 1989/westley in the coming days or I will add it to the bugs file.

I believe then that you can close this issue as complete! Of course there are still bugs to be found and I haven't tested that every entry works but as far as compilation I believe everything is in order - again expected exceptions notwithstanding :-)

I must leave now but I'll try and address more tomorrow - maybe the typos or maybe the final entry here or something else entirely.

Good day!

[xexyl]

QUESTION

I made a change in 1988/westley that lets the program compile as well as ver0 and ver1. The current published one will generate code for all versions that compile with gcc but due to defects in clang not all compile. I think only ver0 compiles with clang. Possibly ver1 in which case below add one to what works and what doesn't. Sorry but not at the laptop to check.

But with the change it's possible to compile another version. A problem though is that I think it's two versions that are not compilable at all due generating bad code.

So there are two possible ways to look at this. This could be an alternate version for clang with the caveat that not as many versions work but more than the current. Or it could be that it's not changed and there is no alternate version.

That might be better thinking about it. But see below.

But I should say that with some versions of clang there's another defect which I fixed for some other entries yesterday as you know: it doesn't allow four args for main().

The first version uses four args I believe so it won't even work with that. The change I made today allows some versions to compile so maybe it should be added as an alternate version?

What do you think? The ideal and eventual goal is to get it to work entirely with clang but that is probably not soon as we have other things to do too.

[lcn2]

QUESTION

I made a change in 1988/westley that lets the program compile as well as ver0 and ver1. The current published one will generate code for all versions that compile with gcc but due to defects in clang not all compile. I think only ver0 compiles with clang. Possibly ver1 in which case below add one to what works and what doesn't. Sorry but not at the laptop to check.

But with the change it's possible to compile another version. A problem though is that I think it's two versions that are not compilable at all due generating bad code.

So there are two possible ways to look at this. This could be an alternate version for clang with the caveat that not as many versions work but more than the current. Or it could be that it's not changed and there is no alternate version.

That might be better thinking about it. But see below.

But I should say that with some versions of clang there's another defect which I fixed for some other entries yesterday as you know: it doesn't allow four args for main().

The first version uses four args I believe so it won't even work with that. The change I made today allows some versions to compile so maybe it should be added as an alternate version?

What do you think? The ideal and eventual goal is to get it to work entirely with clang but that is probably not soon as we have other things to do too.

It is a judgment call to be sure. Your idea of "... an alternate version for clang with the caveat that ..." might work. However as you said, the eventual goal is to get it to work entirely with clang.

[xexyl]

QUESTION

I made a change in 1988/westley that lets the program compile as well as ver0 and ver1. The current published one will generate code for all versions that compile with gcc but due to defects in clang not all compile. I think only ver0 compiles with clang. Possibly ver1 in which case below add one to what works and what doesn't. Sorry but not at the laptop to check.
But with the change it's possible to compile another version. A problem though is that I think it's two versions that are not compilable at all due generating bad code.
So there are two possible ways to look at this. This could be an alternate version for clang with the caveat that not as many versions work but more than the current. Or it could be that it's not changed and there is no alternate version.
That might be better thinking about it. But see below.
But I should say that with some versions of clang there's another defect which I fixed for some other entries yesterday as you know: it doesn't allow four args for main().
The first version uses four args I believe so it won't even work with that. The change I made today allows some versions to compile so maybe it should be added as an alternate version?
What do you think? The ideal and eventual goal is to get it to work entirely with clang but that is probably not soon as we have other things to do too.

It is a judgment call to be sure. Your idea of "... an alternate version for clang with the caveat that ..." might work. However as you said, the eventual goal is to get it to work entirely with clang.

The latter part is definitely true. It might be that the main version which works with some versions of clang at least as far as the entry and ver0 can be there still (of course) but one might enjoy more with an alt version that works with more versions of clang but with the caveat that it doesn't work for every mode. The try section under the alternate code could just omit the extra commands and add a reference to bugs.md which notes the differences. That might be the better way to go about it.

[xexyl]

BTW since you want to help make it look like we're making progress and since we can still interact here when it is closed, you could close this issue as complete! I don't know when I can get to the typos but when I do I don't think it'll take that long.

[xexyl]

I have a proposed change to the Makefiles. I'll quickly do it with sgit and then I will do a commit and pull request. It'll make it easier to compile alt versions without having to edit the Makefile: alt versions if say someone were to work on one but didn't update the Makefile. It also makes it more standard as far as compiling goes.

[xexyl]

I have a proposed change to the Makefiles. I'll quickly do it with sgit and then I will do a commit and pull request. It'll make it easier to compile alt versions without having to edit the Makefile: alt versions if say someone were to work on one but didn't update the Makefile. It also makes it more standard as far as compiling goes.

See commit 1d86daf and the log for rationale. Also for rationale is comment 1628688930. In general better to be standard though I think and I hope you agree!

[lcn2]

Based on comment 1628672908, we are closing this issue with big:

THANK YOU

[xexyl]

Based on comment 1628672908, we are closing this issue with big:

THANK YOU

And THANK YOU TOO!

It's an honour and privilege and a lot of fun! I have also proven to myself how capable I am and the compliments you have given me also feel great so thank you for that too!

I still have some entries to look at but I believe with one exception in some versions of clang every entry at least compiles!

[xexyl]

QUESTION about bug status of 1992/kivinen

Yusuke pointed out that when you start the game everything starts to move over to the right (which I also noticed) but he also noted that if you click the mouse it moves back. I could try locating the problem but I'll have to figure out the mouse code (what it is in other words) in order to do that. It might be good to do that but it might also be valid to consider it a feature as it's documented (it was not documented originally though and I guess it didn't happen originally either).

What do you think?

[lcn2]

QUESTION about bug status of 1992/kivinen

Yusuke pointed out that when you start the game everything starts to move over to the right (which I also noticed) but he also noted that if you click the mouse it moves back. I could try locating the problem but I'll have to figure out the mouse code (what it is in other words) in order to do that. It might be good to do that but it might also be valid to consider it a feature as it's documented (it was not documented originally though and I guess it didn't happen originally either).

What do you think?

This might be one of those "It is not a bug, its a feature" to document in the README.md.

[xexyl]

QUESTION about bug status of 1992/kivinen

Yusuke pointed out that when you start the game everything starts to move over to the right (which I also noticed) but he also noted that if you click the mouse it moves back. I could try locating the problem but I'll have to figure out the mouse code (what it is in other words) in order to do that. It might be good to do that but it might also be valid to consider it a feature as it's documented (it was not documented originally though and I guess it didn't happen originally either).
What do you think?

This might be one of those "It is not a bug, its a feature" to document in the README.md.

And change the status in bugs.md, right?

I'll do that but not today .. will be leaving soon most likely.

[lcn2]

This might be one of those "It is not a bug, its a feature" to document in the README.md.
And change the status in bugs.md, right?

Correct.

I'll do that but not today .. will be leaving soon most likely.

👍

[xexyl]

Sadly I'm aware of another problem with linux. An entry I got working fine with macOS does not work with linux at all. With optimisation it segfaults and without it goes into what appears to be an infinite loop.

I can't deal with it today but I'll deal with it soon I hope. It's the choo choo one. It doesn't work with gcc or clang and the old version didn't either.

[xexyl]

This might be one of those "It is not a bug, its a feature" to document in the README.md.
And change the status in bugs.md, right?

Correct.

I'll do that but not today .. will be leaving soon most likely.

👍

I ended up doing it today after all I think. Might be wrong.

However I'm going to do other things now .. got my booster dose today and just want to take it easy the rest of the day (not because of that but because I am very tired unrelated - been awake a long time though the day has been good).

[xexyl]

This might be one of those "It is not a bug, its a feature" to document in the README.md.
And change the status in bugs.md, right?

Correct.

I'll do that but not today .. will be leaving soon most likely.

👍

I ended up doing it today after all I think. Might be wrong.

However I'm going to do other things now .. got my booster dose today and just want to take it easy the rest of the day (not because of that but because I am very tired unrelated - been awake a long time though the day has been good).

.. actually I solved it. Will do a commit and pull request and then will do other things.

UPDATE 0

.. not so fast: with gcc it works now but not with clang. It segfaults with clang. Will have to solve that first.

[xexyl]

This might be one of those "It is not a bug, its a feature" to document in the README.md.
And change the status in bugs.md, right?

Correct.

I'll do that but not today .. will be leaving soon most likely.

👍

I ended up doing it today after all I think. Might be wrong.
However I'm going to do other things now .. got my booster dose today and just want to take it easy the rest of the day (not because of that but because I am very tired unrelated - been awake a long time though the day has been good).

.. actually I solved it. Will do a commit and pull request and then will do other things.

UPDATE 0

.. not so fast: with gcc it works now but not with clang. It segfaults with clang. Will have to solve that first.

Well this is ugly. With gcc having no optimiser makes it hang. With clang having the optimiser makes it segfault.

I'll have to look at this another time I guess. I'm not sure what to do yet. Maybe another loop is causing the problem but I'll have to investigate it tomorrow - I hope.

[xexyl]

This might be one of those "It is not a bug, its a feature" to document in the README.md.
And change the status in bugs.md, right?

Correct.

I'll do that but not today .. will be leaving soon most likely.

👍

I ended up doing it today after all I think. Might be wrong.
However I'm going to do other things now .. got my booster dose today and just want to take it easy the rest of the day (not because of that but because I am very tired unrelated - been awake a long time though the day has been good).

.. actually I solved it. Will do a commit and pull request and then will do other things.

UPDATE 0

.. not so fast: with gcc it works now but not with clang. It segfaults with clang. Will have to solve that first.

Well this is ugly. With gcc having no optimiser makes it hang. With clang having the optimiser makes it segfault.

I'll have to look at this another time I guess. I'm not sure what to do yet. Maybe another loop is causing the problem but I'll have to investigate it tomorrow - I hope.

Fixed it. Really off to do other things now. Good day!

[lcn2]

Well this is ugly. With gcc having no optimiser makes it hang. With clang having the optimiser makes it segfault.

It might be fun to mention that this once happened in the README.md file and the versions of the compilers on which this happened. Not as a warning, but as a fun fact, for people years from now to read.

While the Makefile can force optimization or lack of optimization in the clang and gov sections, the problem comes when the generic cc (which can be clang or gcc) is used.

For this Makefile, we might want to add a section ahead of the clang and gcc sections, that attempts to determine if cc is really clang or gcc, and then modify the ${CC} variable accordingly.

We shouldn't try to modify the C code source to avoid this problem, we should probably use the compiler with the proper optimization or lack of authorization instead. Then the issue could be submitted to the respective compiler people as a bug report. One can always force the bug, for purposes of the bug report, by explicitly setting of both the ${CC} makefile variable, and forcing the value of the ${OPT} variable.

UPDATE 0

Well we see that you fixed it somehow. So ignore the above.

Well, perhaps there is value in preserving a copy of the code that caused the one compiler to crash and the other optimizer to go into infinite loop for submitting a bug report to the compiler teams?

UPDATE 1

It's sometimes fun to submit such bug reports to compiler teens. Sometimes they are simply amused, sometimes they take the report seriously and dig into the heart of the matter, and sometimes they ignore it as being a weird case. But usually the compiler team, if they can reproduce the bug, identifies a compiler problem and fixes it. When that happens, you are going to be a big help to someone else who might stumble across the same bug with non-obfuscated code.

So if you were interested this as a personal project, you might want to package up the condition and submit it to the compiler teams. This wouldn't be a repo TODO, just something you might find amusing to do.

[xexyl]

Well this is ugly. With gcc having no optimiser makes it hang. With clang having the optimiser makes it segfault.

It might be fun to mention that this once happened in the README.md file and the versions of the compilers on which this happened. Not as a warning, but as a fun fact, for people years from now to read.

While the Makefile can force optimization or lack of optimization in the clang and gov sections, the problem comes when the generic cc (which can be clang or gcc) is used.

For this Makefile, we might want to add a section ahead of the clang and gcc sections, that attempts to determine if cc is really clang or gcc, and then modify the ${CC} variable accordingly.

We shouldn't try to modify the C code source to avoid this problem, we should probably use the compiler with the proper optimization or lack of authorization instead. Then the issue could be submitted to the respective compiler people as a bug report. One can always force the bug, for purposes of the bug report, by explicitly setting of both the ${CC} makefile variable, and forcing the value of the optimizing variable.

Hmm ... well that's a curious thought. What do you think of the fix? It just comments out code and keeps the formatting (ascii art) mostly the same. My concern is that it might not work the way you hope with the Makefile since we can't determine which versions are the problem versions. Some yes but not all. Also what about implementation? I agree that the README.md can be updated though I won't do that today. I'm happy to do it tomorrow.

How do you wish me to proceed?

[lcn2]

I agree that the README.md can be updated though I won't do that today. I'm happy to do it tomorrow.

How do you wish me to proceed?

We recommend that you document the fun fact in the README.md file and consider what we said about packaging up the faulty code to the compiler teams in UPDATE 1 in comment 1633036237 above.

UPDATE 0

We recommend that you leave the current fix in place for this repo.

[xexyl]

I agree that the README.md can be updated though I won't do that today. I'm happy to do it tomorrow.
How do you wish me to proceed?

We recommend that you document the fun fact in the README.md file and consider what we said about packaging up the faulty code to the compiler teams in UPDATE 1 in comment 1633036237 above.

UPDATE 0

We recommend that you leave the current fix in place for this repo.

Funny you should say that as I was going to say that it could be merged and then I would go ahead and try and find the right combination of things - tomorrow. I thought of another idea too that might make it harder - what if the optimiser code changes? In that case the fix might be what's necessary.

However I'd say if you merge the fix we can have record of it so it doesn't get lost. Then I can see if I can figure out a way that doesn't modify the code.

How does that sound? But I won't do it until tomorrow I think.

[xexyl]

Well this is ugly. With gcc having no optimiser makes it hang. With clang having the optimiser makes it segfault.

It might be fun to mention that this once happened in the README.md file and the versions of the compilers on which this happened. Not as a warning, but as a fun fact, for people years from now to read.

While the Makefile can force optimization or lack of optimization in the clang and gov sections, the problem comes when the generic cc (which can be clang or gcc) is used.

For this Makefile, we might want to add a section ahead of the clang and gcc sections, that attempts to determine if cc is really clang or gcc, and then modify the ${CC} variable accordingly.

We shouldn't try to modify the C code source to avoid this problem, we should probably use the compiler with the proper optimization or lack of authorization instead. Then the issue could be submitted to the respective compiler people as a bug report. One can always force the bug, for purposes of the bug report, by explicitly setting of both the ${CC} makefile variable, and forcing the value of the ${OPT} variable.

UPDATE 0

Well we see that you fixed it somehow. So ignore the above.

I did indeed! But see below.

Well, perhaps there is value in preserving a copy of the code that caused the one compiler to crash and the other optimizer to go into infinite loop for submitting a bug report to the compiler teams?

I think that holds some merit yes. It might just be a diff. Or if the other part can be solved - find the right combination of things (after documenting it) - then it can be restored. I'll work on this tomorrow.

UPDATE 1

It's sometimes fun to submit such bug reports to compiler teens. Sometimes they are simply amused, sometimes they take the report seriously and dig into the heart of the matter, and sometimes they ignore it as being a weird case. But usually the compiler team, if they can reproduce the bug, identifies a compiler problem and fixes it. When that happens, you are going to be a big help to someone else who might stumble across the same bug with non-obfuscated code.

So if you were interested this as a personal project, you might want to package up the condition and submit it to the compiler teams. This wouldn't be a repo TODO, just something you might find amusing to do.

That does sound kind of fun! Though I'm not sure what I would say .. yet. I'll think on it. I guess somehow that they would call it not a bug because of the code I commented out that causes the problem. I am not a compiler writer but I guess that the optimiser removes that faulty code (or loop). Well I don't really guess that but it popped into my head anyway. I'm not sure what the problem would be in full esp as different compilers do it differently.

Still I'd have to come up with the right combination of things first. That can happen after the merge and I have more time.

[lcn2]

I thought of another idea too that might make it harder - what if the optimiser code changes?

Compiler people break the compiler on a regular basis. Sometimes it's their own fault and sometimes it's because the ANSI C committee, looking for a reason to meet in nice places for their standards, meetings, much up to C language, requiring compiler people to do stranger in stranger things to the C compiler.

In the past the compiler teams have use the IOCCC code as regression tests. They might not do that now because, well all the problems we uncovered with compiling using modern compiler, made such regression tests, less useful.

It is common for the IOCCC to include submissions in that cause a C compiler to crash or run into problems. We have no doubt that future compilers will stumble over obfuscated code. :-)

[xexyl]

I thought of another idea too that might make it harder - what if the optimiser code changes?

Compiler people break the compiler on a regular basis. Sometimes it's their own fault and sometimes it's because the ANSI C committee, looking for a reason to meet in nice places for their standards, meetings, much up to C language, requiring compiler people to do stranger in stranger things to the C compiler.

Indeed:

 * The history of the IOCCC has taught us that even minor changes
 * to the language are not always well understood by compiler writers,
 * let alone the standards body who publishes them. We have enormous
 * sympathy for C compiler writers who must keep up with the creeping
 * featurism.  We are aware of some C standards members who share
 * these concerns.  Alas, they seem to be a minority.
 
...

:-)

In the past the compiler teams have use the IOCCC code as regression tests. They might not do that now because, well all the problems we uncovered with compiling using modern compiler, made such regression tests, less useful.

That's fun! I did not know that part. Or maybe I did .. not sure. Thanks! I can see how it wouldn't happen now though.

It is common for the IOCCC to include submissions in that cause a C compiler to crash or run into problems. We have no doubt that future compilers will stumble over obfuscated code. :-)

I know and neither do I! :-)

[xexyl]

I thought of another idea too that might make it harder - what if the optimiser code changes?

Compiler people break the compiler on a regular basis. Sometimes it's their own fault and sometimes it's because the ANSI C committee, looking for a reason to meet in nice places for their standards, meetings, much up to C language, requiring compiler people to do stranger in stranger things to the C compiler.

Indeed:

 * The history of the IOCCC has taught us that even minor changes
 * to the language are not always well understood by compiler writers,
 * let alone the standards body who publishes them. We have enormous
 * sympathy for C compiler writers who must keep up with the creeping
 * featurism.  We are aware of some C standards members who share
 * these concerns.  Alas, they seem to be a minority.
 
...

:-)

In the past the compiler teams have use the IOCCC code as regression tests. They might not do that now because, well all the problems we uncovered with compiling using modern compiler, made such regression tests, less useful.

That's fun! I did not know that part. Or maybe I did .. not sure. Thanks! I can see how it wouldn't happen now though.

It is common for the IOCCC to include submissions in that cause a C compiler to crash or run into problems. We have no doubt that future compilers will stumble over obfuscated code. :-)

I know and neither do I! :-)

Lints are also fun. I've made them segfault before.

[xexyl]

I agree that the README.md can be updated though I won't do that today. I'm happy to do it tomorrow.
How do you wish me to proceed?

We recommend that you document the fun fact in the README.md file and consider what we said about packaging up the faulty code to the compiler teams in UPDATE 1 in comment 1633036237 above.

UPDATE 0

We recommend that you leave the current fix in place for this repo.

Funny you should say that as I was going to say that it could be merged and then I would go ahead and try and find the right combination of things - tomorrow. I thought of another idea too that might make it harder - what if the optimiser code changes? In that case the fix might be what's necessary.

However I'd say if you merge the fix we can have record of it so it doesn't get lost. Then I can see if I can figure out a way that doesn't modify the code.

How does that sound? But I won't do it until tomorrow I think.

Commit d792fbf adds commentary on it and adds alt code: the code that is broken depending on the compiler (or maybe the compiler is broken :-) .. not sure).

I think this is better than trying to work out how to set the optimiser level or not as it seems like needless complication.

[xexyl]

Hmm ... from 2014/endoh1 if you run make rake you get:

gcc -Wall -W -Wextra -o prog prog.c -g
prog.c: In function 'main':
prog.c:45:97: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
   45 |                 ;}re    turnY_.",*p,    b,d[        9338    ],*q,x,*r=d;            int main(){;for(
      |                                                                                                 ^~~
prog.c:46:95: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
   46 |                 p=q=    5000+0+d;*s;    s++)        if(*    s>32)*p++=*s            -89?*s:32;for(p=
      |                                                                                               ^~~
prog.c:48:81: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
   48 |                 92&&                    34<b    --;*r++=x)if(x==9*9)            for(    ;*q;x=34
      |                                                                                 ^~~
prog.c:49:28: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
   49 |                 )*r++=*q++;for(p-=b<92;b-->4        *23;r++)    *r=r[36-    x];}puts    (d);
      |                            ^~~

Do you want me to update the Rakefile to pass the option to silence that warning? Actually I just did it .. will make a pull request if you agree that it should be done. But for now I'm off to do other things for the day most likely.

[xexyl]

Hmm ... from 2014/endoh1 if you run make rake you get:

gcc -Wall -W -Wextra -o prog prog.c -g
prog.c: In function 'main':
prog.c:45:97: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
   45 |                 ;}re    turnY_.",*p,    b,d[        9338    ],*q,x,*r=d;            int main(){;for(
      |                                                                                                 ^~~
prog.c:46:95: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
   46 |                 p=q=    5000+0+d;*s;    s++)        if(*    s>32)*p++=*s            -89?*s:32;for(p=
      |                                                                                               ^~~
prog.c:48:81: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
   48 |                 92&&                    34<b    --;*r++=x)if(x==9*9)            for(    ;*q;x=34
      |                                                                                 ^~~
prog.c:49:28: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
   49 |                 )*r++=*q++;for(p-=b<92;b-->4        *23;r++)    *r=r[36-    x];}puts    (d);
      |                            ^~~

Do you want me to update the Rakefile to pass the option to silence that warning? Actually I just did it .. will make a pull request if you agree that it should be done. But for now I'm off to do other things for the day most likely.

Doing it with another fix too ...