5 ms·

That’s a very old version of C. The function signature of main uses the old K&R style for function parameters. I doubt it would compile currently!

bawolff 3y ago
It literally has 1988 in the title.
- chris_wot 3y ago
  One self evident statement does not invalidate the other :-)
uxp8u61q 3y ago
It does compile, even with `-std=c17` under GCC. With a few warnings about implicit `int`s, of course. Even `-Wall` only adds a single warning (about !0<t not meaning what you could think it means.)
- benj111 3y ago
  That's very presumptuous of GCC to assume that it thinks it knows that what I think !0<t means is wrong. I wonder if NaN is larger then !0
  - uxp8u61q 3y ago
    I wrote "could think", calm down.
deleted 3y ago
[deleted]
arp242 3y ago
> I doubt it would compile currently! It compiles (and runs!) fine with just "gcc a.c"; nothing more needed. clang does throw some fatal errors, but there's probably some combination of flags to make it work; I couldn't be bothered to look further. I've compiled plenty of code from the 80s; I can't recall a single example where it didn't work that wasn't due to OS-specific stuff. Tons of warnings and maybe some special-flags? Sure. But it works. There's even some modern (well, "modern") code around today that uses K&R style function parameters.
- throwawaymobule 3y ago
  I'm sure a few compiler maintainers take pride in making sure certain 'famous' code snippets still compile as time goes on.
  - hnfong 3y ago
    IOCCC is "test cases for free", so if C compilers haven't added these code to their testing suite they really should.
- orf 3y ago
  What modern code are you referencing?
  - arp242 3y ago
    Most if not all of bash. zlib changed it just a few months ago (1.3 release from August): https://github.com/madler/zlib/issues/633 https://github.com/madler/zlib/issues/633 I've also seen it in some FreeBSD code, but that was quite a few years ago and I don't know to what degree that's been cleaned up – not so easy to grep for, but a quick check in git log shows e.g. https://github.com/freebsd/freebsd-src/commit/e5d0d1c5fbbc https://github.com/freebsd/freebsd-src/commit/e5d0d1c5fbbc and some other things, so it seems there's still some K&R around. Probably others as well, this is what I happen to know from the top of my head.
- Cockbrand 3y ago
  TIL that on macOS, both `gcc` and `clang` are present, but `/usr/bin/gcc` is in fact just a hard link to `/usr/bin/clang`. So I couldn't compile it with gcc (which is clang) on the Mac, but it compiles just fine with gcc on Linux. It's really astonishing that we can compile 35 years old code with our current tooling. I somehow doubt that we'll be able to compile 35 years old Java/Go/Rust/... code without changes in the futue.
  - arp242 3y ago
    That's surprising! But I kind of get why they do that, as so many tools hard-code "gcc" rather than using "cc" or "$CC". I'm not all that familiar with Java or Rust, but Go is very compatible; it's hard to predict the future, but it's already a third on its way to "35 years of compatibility". JavaScript is pretty compatible as well; crummy JS from the 90s typically still works today (arguably it's compatible to a fault, with things like arr[-1] not being fixed).
School-Cotton 3y ago
There’s a lot of code in even the modern forks of BSD (Free, Open, etc) in that style. Still compiles fine!

bawolff 3y ago

It literally has 1988 in the title.

chris_wot 3y ago
One self evident statement does not invalidate the other :-)

uxp8u61q 3y ago

It does compile, even with `-std=c17` under GCC. With a few warnings about implicit `int`s, of course. Even `-Wall` only adds a single warning (about !0<t not meaning what you could think it means.)

benj111 3y ago
That's very presumptuous of GCC to assume that it thinks it knows that what I think !0<t means is wrong. I wonder if NaN is larger then !0
- uxp8u61q 3y ago
  I wrote "could think", calm down.

deleted 3y ago

[deleted]

arp242 3y ago

> I doubt it would compile currently! It compiles (and runs!) fine with just "gcc a.c"; nothing more needed. clang does throw some fatal errors, but there's probably some combination of flags to make it work; I couldn't be bothered to look further. I've compiled plenty of code from the 80s; I can't recall a single example where it didn't work that wasn't due to OS-specific stuff. Tons of warnings and maybe some special-flags? Sure. But it works. There's even some modern (well, "modern") code around today that uses K&R style function parameters.

throwawaymobule 3y ago
I'm sure a few compiler maintainers take pride in making sure certain 'famous' code snippets still compile as time goes on.
- hnfong 3y ago
  IOCCC is "test cases for free", so if C compilers haven't added these code to their testing suite they really should.
orf 3y ago
What modern code are you referencing?
- arp242 3y ago
  Most if not all of bash. zlib changed it just a few months ago (1.3 release from August): https://github.com/madler/zlib/issues/633 https://github.com/madler/zlib/issues/633 I've also seen it in some FreeBSD code, but that was quite a few years ago and I don't know to what degree that's been cleaned up – not so easy to grep for, but a quick check in git log shows e.g. https://github.com/freebsd/freebsd-src/commit/e5d0d1c5fbbc https://github.com/freebsd/freebsd-src/commit/e5d0d1c5fbbc and some other things, so it seems there's still some K&R around. Probably others as well, this is what I happen to know from the top of my head.
Cockbrand 3y ago
TIL that on macOS, both `gcc` and `clang` are present, but `/usr/bin/gcc` is in fact just a hard link to `/usr/bin/clang`. So I couldn't compile it with gcc (which is clang) on the Mac, but it compiles just fine with gcc on Linux. It's really astonishing that we can compile 35 years old code with our current tooling. I somehow doubt that we'll be able to compile 35 years old Java/Go/Rust/... code without changes in the futue.
- arp242 3y ago
  That's surprising! But I kind of get why they do that, as so many tools hard-code "gcc" rather than using "cc" or "$CC". I'm not all that familiar with Java or Rust, but Go is very compatible; it's hard to predict the future, but it's already a third on its way to "35 years of compatibility". JavaScript is pretty compatible as well; crummy JS from the 90s typically still works today (arguably it's compatible to a fault, with things like arr[-1] not being fixed).

School-Cotton 3y ago

There’s a lot of code in even the modern forks of BSD (Free, Open, etc) in that style. Still compiles fine!