3 ms·
> IOCCC entries will absolutely become more fun though. IOCCC doesn't allow unescaped octets with high bit set [1], so even that's no go. [1] https://www.iocc
by lifthrasiir 5y ago
> IOCCC entries will absolutely become more fun though.
IOCCC doesn't allow unescaped octets with high bit set [1], so even that's no go.
[1] https://www.ioccc.org/2020/rules.txt https://www.ioccc.org/2020/rules.txt (rule 13)
- Groxx 5y agoAww. But also of course they've already addressed this.
- saagarjha 5y agoI am very curious which program abused this and forced the creation of that rule.
- lifthrasiir 5y agoProbably 2000/briddlebane [1]. But it is more like a guard against compatibility issues. [1] https://www.ioccc.org/2000/briddlebane.c https://www.ioccc.org/2000/briddlebane.c vs. https://www.ioccc.org/2000/briddlebane.orig.c https://www.ioccc.org/2000/briddlebane.orig.c
- GlitchMr 5y agoWell, technically the rule only talks about entries that "fail to compile". An entry that still compiles is fine, see rule 12. In practice this means the Unicode abuse like this is only allowed in strings.
- lifthrasiir 5y agoWhen the rule was originally introduced in 2001 [1] it was a total ban. It seems that the rule was slightly relaxed in 2013 [2], but I think it still massively discourages any octet >= 128 because there is no portable way to set the input encoding (like GCC `-finput-charset`, which is ignored by Clang AFAIK). [1] https://www.ioccc.org/2001/rules https://www.ioccc.org/2001/rules [2] https://www.ioccc.org/2013/rules.txt https://www.ioccc.org/2013/rules.txt