Live data from Hacker News

First C compiler ported to GCC

github.com

61–70 of 90 posts

Re: First C compiler ported to GCC

#61
post #57

Earlier quoted context omitted.

https://www.bell-labs.com/usr/dmr/www/chist.html > To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

Yes, I'm not arguing against such warnings in general. I'm arguing against pure coding style type warnings. Here's an example: If you do an '==' comparison inside an if, you might accidentally type '=' instead, making it a perfectly valid assignment. The gcc developers eventually decided to issue a warning if you do an assignment inside an 'if' conditional, but give you the option to put another set of parantheses ar…

I see.

Re: First C compiler ported to GCC

#62

Earlier quoted context omitted.

How does this work in C++ with operator overloading. Are they still the same? That would make for some interesting obfuscated code.

> How does this work in C++ with operator overloading. you can't overload int::operator[](...)

I guess the question was whether the subscript operator is always assumed commutative in C++.

Re: First C compiler ported to GCC

#63

Earlier quoted context omitted.

Not everything needs a valid use case. It can exist just for fun.

The thing is, the more complex a spec is (or rather, how much stuff it allows that will never be used), the bigger the danger is that somewhen down the line, this will introduce a security or other issue.

I think the assumption that addition is commutative in any context simplifies the spec rather than makes it more complex.

Re: First C compiler ported to GCC

#64
post #63

Earlier quoted context omitted.

The thing is, the more complex a spec is (or rather, how much stuff it allows that will never be used), the bigger the danger is that somewhen down the line, this will introduce a security or other issue.

I think the assumption that addition is commutative in any context simplifies the spec rather than makes it more complex.

It however is not "natural" for someone who doesn't know the obscure bits of history in a standard written many decades ago.

Someone writing, say, a static code analysis tool or an IDE may not assume that it is possible that in the expression `a[b]` a may be something else than a pointer / array.

Re: First C compiler ported to GCC

#65

Earlier quoted context omitted.

Hence why it "can be written" as b[a] as well Edit: it doesn't blow up, not even with -Wall and -std=c99

> (yes it will probably blow up in modern compilers, or at least give you a warning) Nope. For the code snippet I posted an hour ago, even with -pedantic -Wall -Wextra gcc won't issue any warnings. And why should it? It's perfectly standards conformant, because the standard actually defines the [] operator through the equivalent addition expression.

if (x = 5) is standards conforming but every compiler that warns about anything warns about potentially confusing = and ==.

Re: First C compiler ported to GCC

#66
post #63

Earlier quoted context omitted.

I think the assumption that addition is commutative in any context simplifies the spec rather than makes it more complex.

It however is not "natural" for someone who doesn't know the obscure bits of history in a standard written many decades ago. Someone writing, say, a static code analysis tool or an IDE may not assume that it is possible that in the expression `a[b]` a may be something else than a pointer / array.

But pointer arithmetic is not "obscure bits of history."

Re: First C compiler ported to GCC

#67
post #63

Earlier quoted context omitted.

I think the assumption that addition is commutative in any context simplifies the spec rather than makes it more complex.

It however is not "natural" for someone who doesn't know the obscure bits of history in a standard written many decades ago. Someone writing, say, a static code analysis tool or an IDE may not assume that it is possible that in the expression `a[b]` a may be something else than a pointer / array.

> Someone writing, say, a static code analysis tool or an IDE may not assume

If you're writing a static analysis tool or an IDE then I think it's fine to expect you to read the spec.

Re: First C compiler ported to GCC

#68

Did this compiler really support "auto" as a variable type, as seen in example fizzbuzz ?

No. "auto" is not a type but a storage class that means automatically allocated instead of being allocated to a register, extern-al to the file, or in the static code segment.

Re: First C compiler ported to GCC

#70
post #57

Earlier quoted context omitted.

https://www.bell-labs.com/usr/dmr/www/chist.html > To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

Yes, I'm not arguing against such warnings in general. I'm arguing against pure coding style type warnings. Here's an example: If you do an '==' comparison inside an if, you might accidentally type '=' instead, making it a perfectly valid assignment. The gcc developers eventually decided to issue a warning if you do an assignment inside an 'if' conditional, but give you the option to put another set of parantheses ar…

Accidental assignment affects program correctness. Commutative array indexing has no impact on behavior.
Post reply on HN