Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C implementation of Tic-Tac-Toe in a single call to printf

github.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: C implementation of Tic-Tac-Toe in a single call to printf

#61

Post by codezero »

russfink wrote: post #43
simias wrote: post #35

Oddly enough I find that the #define macro soup detracts from the performance here. I was rather unimpressed at first because obfuscating C code by just #define'ing a bunch of code is a trivial and rather uninteresting way to write unreadable code. Of course you can make any arbitrary code look like a printf call with enough macros! But it's actually a lot more clever than that. I feel like this would be a lot more i…

One time, I had to maintain C code That somebody had #define'd to look like FORTRAN. It was impressive.

One time, I had to maintain FORTRAN code. Much of it was still in FORTRAN 66.

Re: C implementation of Tic-Tac-Toe in a single call to printf

#62

Post by haberman »

In case you're wondering (like me) how you'd get input from printf():

> We ab^H^Huse [the Turing-completeness of printf()] to implement a the logic of tic-tac-toe entirely within this one printf call (and a call to scanf() to read user input).

So it should be "one printf() and one scanf()."

Re: C implementation of Tic-Tac-Toe in a single call to printf

#64

Post by saagarjha »

Someone wrote: post #60
hibbelig wrote: post #47

Earlier quoted context omitted.

Alas, it's technically difficult to get input from the user using printf.

If you’re willing to lose almost all portability, I think you could read a value from an I/O port, pass that to printf , use that as the field width for a string to print, count the character length of the resulting string using %n to move it into a variable, and then backspace over that to prevent the output from dirtying your output. You could only use the results in a subsequent call to printf , though. Of course,…

In that case it might just be easier to ROP your way to scanf.

Re: C implementation of Tic-Tac-Toe in a single call to printf

#66

Post by Gene_Parmesan »

simias wrote: post #49
russfink wrote: post #43

Earlier quoted context omitted.

One time, I had to maintain C code That somebody had #define'd to look like FORTRAN. It was impressive.

I've had to deal with code like that, only poorly mimicking Lisp instead: `#define unless(_x) if (!(_x))` etc... One of my favourite accidental features in Rust is that macros are so annoying and cryptic to write that people think twice before abusing them.

Wouldn't be surprised if that was intentional, actually. The idea of making syntax a little unwieldy for things that you should really think twice before using is not a new one.

Re: C implementation of Tic-Tac-Toe in a single call to printf

#67

Post by sfoley »

haberman wrote: post #62

In case you're wondering (like me) how you'd get input from printf(): > We ab^H^Huse [the Turing-completeness of printf()] to implement a the logic of tic-tac-toe entirely within this one printf call (and a call to scanf() to read user input). So it should be "one printf() and one scanf()."

Should be "an infinite number of printf()s and scanf()s".

Re: C implementation of Tic-Tac-Toe in a single call to printf

#68

Post by ufo »

coliveira wrote: post #59
simias wrote: post #35

Oddly enough I find that the #define macro soup detracts from the performance here. I was rather unimpressed at first because obfuscating C code by just #define'ing a bunch of code is a trivial and rather uninteresting way to write unreadable code. Of course you can make any arbitrary code look like a printf call with enough macros! But it's actually a lot more clever than that. I feel like this would be a lot more i…

The reason he had to use macros is that the actual formatting string is huge and difficult to understand. In this case, macros really serve a useful purpose, instead of just obfuscating code.

Another reason is that this was intended as an IOCCC submission and IOCCC has a file size limit.

Re: C implementation of Tic-Tac-Toe in a single call to printf

#69

Post by gamegoblin »

russfink wrote: post #43
simias wrote: post #35

Oddly enough I find that the #define macro soup detracts from the performance here. I was rather unimpressed at first because obfuscating C code by just #define'ing a bunch of code is a trivial and rather uninteresting way to write unreadable code. Of course you can make any arbitrary code look like a printf call with enough macros! But it's actually a lot more clever than that. I feel like this would be a lot more i…

One time, I had to maintain C code That somebody had #define'd to look like FORTRAN. It was impressive.

Much of the original Bourne shell was written in C that had been macro'd to look like Algol [1].

E.g.

    /usr/src/cmd/sh/mac.h:
    #define IF      if(
    #define THEN    ){
    #define ELSE    } else {
    #define ELIF    } else if (
    #define FI      ;}
    
    #define BEGIN   {
    #define END     }
    #define SWITCH  switch(
    #define IN      ){
    #define ENDSW   }
    #define FOR     for(
    #define WHILE   while(
[1] https://research.swtch.com/shmacro

Re: C implementation of Tic-Tac-Toe in a single call to printf

#70

Post by keitmo »

russfink wrote: post #43
simias wrote: post #35

Oddly enough I find that the #define macro soup detracts from the performance here. I was rather unimpressed at first because obfuscating C code by just #define'ing a bunch of code is a trivial and rather uninteresting way to write unreadable code. Of course you can make any arbitrary code look like a printf call with enough macros! But it's actually a lot more clever than that. I feel like this would be a lot more i…

One time, I had to maintain C code That somebody had #define'd to look like FORTRAN. It was impressive.

"The determined Real Programmer™ can write FORTRAN in any language."
Post reply on HN