Future Rule 2b computed size change?

[SirWumpus]

I've been thinking about this the past couple of years and how the judges feel about the following question: Does compacting a program to use single letters for identifiers really help with obfuscation any more or is it a tired "trope"?

Back in the day compacting functions and variables to single letters helped get the program within the size limits of Rule 2. There was a time too that this would aid in obfuscation (I remember one winner using combinations of o for all the identifiers). But has its time as an obfuscation technique become tired?

Do the judges still find this interesting or are they now more interested in interesting concepts, data structures, and techniques and less so in the visual appearance (excluding the best layout winners). Would the use of proper meaningful (for some definition thereof) identifiers be just as good?

Imagine for example someone using all the words from "Jabberwocky" as identifiers in some order. You'd blow Rule 2 limit easy, but it should prove different. Is it worth considering for some future contest (not necessarily the next, maybe the next next one?) adding a new clause to Rule 2b such that:

All identifiers count at most two (2) octets towards Rule 2b.?

Not sure if C library et al. should be count as-is or subject to the rule, just the developer's identifiers?

This would mean programs would start to appear more de-obfuscated for reading, while still bound in size. With a refocus on teaching and learning is this something to consider? (Maybe a new side contest? The IDCCC = Intl. Deobfuscated C Code Contest 😁).

[xexyl]

Yes it does especially if it's something that looks like something else. l can, depending on font, look like the digit 1. I actually have done this and I'm sure others have too.

That's just one example. Also it makes the program more compact even if it's not more obscure. That has some nice benefits too.

Plus the size increase is not at this point final as they have said.

Besides, even if it doesn't help obscure the code it doesn't mean it's bad to have it. I think it does, though, because it's a lot harder to keep track of single letter identifiers than names.

Also, as they say, they like well rounded obfuscation. If it was just single letter identifiers that would not win anyway.

[SirWumpus]

Another example would be an entry where the identifiers are UTF-8 multibyte characters, consider how obfuscated an entry would look written in mix of Japanese, German, and Sanskrit. It certainly would be obfuscated to most readers.

[xexyl]

Another example would be an entry where the identifiers are UTF-8 multibyte characters, consider how obfuscated an entry would look written in mix of Japanese, German, and Sanskrit. It certainly would be obfuscated to most.

The 'private tool' I was asked to write (and that's all I'll say :-) ) actually has some German in it but not noticeable as German.

There certainly are cases where longer names can help with obfuscation but so too can single letters. It's not about JUST identifier names either.

Consider this too: it's been over four years since the contest was open. I bet many people have already written code for the contest and to make them not use single letter identifiers would be really cruel and not fair.

[SirWumpus]

Also it makes the program more compact even if it's not more obscure. That has some nice benefits too.

Compact code is not necessarily interesting any more, consider the Rule 2b changes to move away from "blob" code.

[xexyl]

Also it makes the program more compact even if it's not more obscure. That has some nice benefits too.

Compact code is not necessarily interesting any more, consider the Rule 2b changes to move away from "blob" code.

True but the judges also don't like code that is bigger than it has to be.

Compact code doesn't have to be a blob either. It certainly can be but just because code is compact doesn't mean it's blobby.

I do like code in the contest that has longer identifiers but I also appreciate single character names. In the case of my entries it helps fit them on shirts. But that part is obviously a more personal reason (that also doesn't change anything above).

[SirWumpus]

to make them not use single letter identifiers would be really cruel and not fair.

I'm not saying to disallow single letters, just allow moving away from it. Note:

All identifiers count at most two (2) octets towards Rule 2b.?

I said ... at most two ... so if you used single letters, they would count as one still.

[xexyl]

I will add something though: I do like the idea of having diacritics in code. That could be fun and it would be a new way of obfuscating, to be sure. It would also solve a problem with running out of letters as one could use for instance é, ë and so on, assuming it's all valid.

In fact it would have been very fun to do for the Enigma machine of 2020! I would have probably enjoyed that.

[SirWumpus]

... one could use for instance é, ë and so on, assuming it's all valid.

For the purpose of C I would think each character with/without diacritics would be treated differently, much like upper and lower case is different. In a French dictionary they group the words by e, ë, é, è (not as just 'e'). Same would be true of Hirigana and Katakana, same alphabet, but different glyphs (katakana is used for foreign words typically).

[xexyl]

... one could use for instance é, ë and so on, assuming it's all valid.

For the purpose of C I would think each character with/without diacritics would be treated differently, much like upper and lower case is different. In a French dictionary they group the words by e, ë, é, è (not as just 'e'). Same would be true of Hirigana and Katakana, same alphabet, but different glyphs (katakana is used for foreign words typically).

And then there's the debate in German: are they part of the alphabet or not. And then there's the Eszett (ẞ).

I am not fluent in German (far from it!) but I know a bit and I find it a beautiful language (I know many people find it the opposite though); French I know absolutely nothing about except I don't know that I like it. I don't know if that's true and I know there are some really funny things about it (something to do with numbers to not get into rude things) but maybe I just don't like the sound of it. Maybe I haven't heard it enough to let it grow on me. Either way I know next to nothing if not nothing about it.

I did have a thought that (and this is just a thought that popped into my head - I have absolutely no idea whether it's a good idea or not) maybe characters with diacritics (or the Eszett) might be counted as 2 bytes (or N+1 where N is what we had valid in the contest before) but I don't know what I would think about it either. It just popped into my head. If the size limit went back down I would definitely not want it but I guess that's not any more certain than your idea here.

I do really appreciate the dialogue btw and your clarifying things too.

[SirWumpus]

maybe characters with diacritics (or the Eszett) might be counted as 2 bytes

No point. Once you start talking characters, the idea of byte counting is pointless for text. Anyway most european alphabets are UTF8 2 byte sequences, while the Asain ones I think are 3 and/or 4 byte sequences. If you count by bytes, you penalise non-europeans for using their native alphabet.

[xexyl]

maybe characters with diacritics (or the Eszett) might be counted as 2 bytes

No point. Once you start talking characters, the idea of byte counting is pointless for text. Anyway most european alphabets are UTF8 2 byte sequences, while the Asain ones I think are 3 and/or 4 byte sequences. If you count by bytes, you penalise non-europeans for using their native alphabet.

That's true enough. It just popped into my head and thought I'd mention it. It would in a way penalise them but on the other hand they get to use extra characters. But then again ... that's not really nice and your point about size is also valid of course. Admittedly this was another concern of mine here anyway.

[SirWumpus]

@lcn2 Any thoughts on #903 (reply in thread) ?

[lcn2]

@lcn2 Any thoughts on #903 (reply in thread) ?

None at this time that we wish to make.

Although is almost certain that such a shift would not occur without a lot of internal IOCCC judge discussion. The changes to rule 2 sizes were controversial and complex enough (and are still not fully settled, BTW). Our guess that anything close to what is being discussed might be post IOCCC28 at best (if it happens at all), but that is just a guess.

That's why we remain silent observers in this discussion.

[xexyl]

@lcn2 Any thoughts on #903 (reply in thread) ?

None at this time that we wish to make.

Although is almost certain that such a shift would not occur without a lot of internal IOCCC judge discussion. The changes to rule 2 sizes were controversial and complex enough (and are still not fully settled, BTW). Our guess that anything close to what is being discussed might be post IOCCC28 at best (if it happens at all), but that is just a guess.

That's why we remain silent observers in this discussion.

No longer silent though! :-)

It makes sense what you say though.

[SirWumpus]

The changes to rule 2 sizes were controversial and complex enough (and are still not fully settled, BTW).

That would be an interesting discussion to hear.

Though I see no conflict or issue between the size changes and UTF8 support. One concerns size, the other embraces multibyte characters like the C standard. The more I think about the idea to move from octets to characters, the more I believe its time to make an effort to move from 1980's thinking in terms of ASCII only. UTF8 multibyte support has been around a long time now.

But that is just me.

[xexyl]

The changes to rule 2 sizes were controversial and complex enough (and are still not fully settled, BTW).

That would be an interesting discussion to hear.

Though I see no conflict or issue between the size changes and UTF8 support. One concerns size, the other embraces multibyte characters like the C standard. The more I think about the idea to move from octets to characters, the more I believe its time to make an effort to move from 1980's thinking in terms of ASCII only. UTF8 multibyte support has been around a long time now.

But that is just me.

I'd like to hear that discussion too but I guess it's something only judges get to hear. The other part is a nice idea and I'm starting to like it too .. though I guess not sure entirely.

Have a great rest of your day and thanks for the dialogue! Off for the night.

[SirWumpus]

UTF-8 demands equal rights and respect as real characters! The dominance of slim ASCII must end! We are the UTF-8 People's Front for Freedom, Equality, and Brotherhood (oh that's been used already) - We are the UTF-8 Countless Tourist Defence Farce for One Voice, One World, One Character Set.

For comparison and future consideration I have implemented an extension to (the original) iocccsize with UTF-8 character counting. This should allow to compare byte vs character size differences, with a goal to eventually change the Rule 2 wording to count by character, instead of bytes.

The -v1 output has been enhanced...

$ iocccsize -v1 prog.c
2a_net 2b_gross 2a_mb_net 2b_mb_gross keywords

[lcn2]

After an extended conversation with Leo, we have determined that we will NOT change Rule 2a from bytes to UTF-8 characters. We know that this puts UTF-8 variables and function names at a disadvantage, but so is ASCII variables and function names. Leo was unhappy with the recent size change and was definite about not modifying the Rule 2a anytime soon.

There is pondering about changing Rule 2b to consider counting UTF-8 characters, however, but that is an on-going discussion. We might look into this for IOCCC30, however such a Rule 2b change would still have to fit within the Rule 2a byte limits.

Sorry (tm Canada 🇨🇦), this may not have been the answer you have wanted.

[SirWumpus]

This is fine. You the Judges had made that statement before. I did not think 29 or 30 would adopt this change. I simply made the tweak, as diagnostic information, for far future consideration and comparative. At least if the tool has the ability, you could look at the numbers in IOCCC29, IOCCC30, IOCCC31. I'm thinking this is a future direction AFTER, the recent rule change runs its course. Odds are my little UTF-8 usage example will remain an oddity.