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

First C compiler ported to GCC

github.com

Post reply on HN
Print view View original

51–60 of 90 posts

Re: First C compiler ported to GCC

#51

Post by cat199 »

mschuster91 wrote: post #42
st_goliath wrote: post #31

Earlier quoted context omitted.

And that's how it's still taught nowadays. Both the C89 and the C99 standard draft contain the following: > The definition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))) In fact the expressions a[b] *(a + b) and b[a] are equivalent. Here is a perfectly valid snippet of C code that will print out 't': putchar(3["test"]);

I understand why that example works but I struggle finding a valid use-case, aside from code golfing...

speculating, but don't think it's about use case so much as it is about it being a simple way to implement ('C is portable assembly') which probably carried through to our more current notion of this being a 'language level' thing

Re: First C compiler ported to GCC

#52

Post by st_goliath »

yakubin wrote: post #47
st_goliath wrote: post #40

Earlier quoted context omitted.

So you expect to compiler to give you style points for your code? To be clear: it isn't just coincidentally identical behaviour, it is defined by the standard to be equivalent.

Most compilers will warn about misleading indentation. This is misleading indexing. A program containing misleading indentation is also standards-compliant, but that's completely irrelevant when talking about what code should trigger warnings.

Misleading indentations, unused variables, unused goto labels and the like are a quite good indicator that there is something wrong here. The thing we are talking about here is issuing warnings for "but that's not how we usually do it".

When you add a new warning to a C compiler, you will break build processes all over the planet that have "-Werror" turned on and/or have management that insists on warnings being addressed. Some of those build processes compile decade old, safety critical production code. Code that has a couple hairy, stylistically sucky places in it. Code that sometimes does weird but perfectly valid things because those portions were ported over from assembly back in the 80ies. (And yes, I can guarantee you first hand that the situation I describe here is very real)

C compilers have become critical infrastructure and meddling with their internals and their behavior poses real word risks. Adding a whole new compiler warning must be carefully considered and better have a damn good reason.

"This pattern in the syntax tree strongly indicates that there is something wrong in the code" is a good reason.

"This is not how I usually write code" needlessly forces people to rewrite finicky code that has been working perfectly for decades in safety critical environments, for no reason other than you not liking e.g. the order of operator arguments.

Re: First C compiler ported to GCC

#53

Post by jcelerier »

kevincox wrote: post #48
st_goliath wrote: post #31

Earlier quoted context omitted.

And that's how it's still taught nowadays. Both the C89 and the C99 standard draft contain the following: > The definition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))) In fact the expressions a[b] *(a + b) and b[a] are equivalent. Here is a perfectly valid snippet of C code that will print out 't': putchar(3["test"]);

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[](...)

Re: First C compiler ported to GCC

#54

Post by charcircuit »

mschuster91 wrote: post #42
st_goliath wrote: post #31

Earlier quoted context omitted.

And that's how it's still taught nowadays. Both the C89 and the C99 standard draft contain the following: > The definition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))) In fact the expressions a[b] *(a + b) and b[a] are equivalent. Here is a perfectly valid snippet of C code that will print out 't': putchar(3["test"]);

I understand why that example works but I struggle finding a valid use-case, aside from code golfing...

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

Re: First C compiler ported to GCC

#55

Post by sneak »

yakubin wrote: post #47
st_goliath wrote: post #40

Earlier quoted context omitted.

So you expect to compiler to give you style points for your code? To be clear: it isn't just coincidentally identical behaviour, it is defined by the standard to be equivalent.

Most compilers will warn about misleading indentation. This is misleading indexing. A program containing misleading indentation is also standards-compliant, but that's completely irrelevant when talking about what code should trigger warnings.

I think that perhaps this has ventured into the job of linter or stylechecker. It's definitely not compiler warning territory.

When I learned C as a teenager from k&r I learned that these statements are absolutely equivalent, and I was surprised to see it even mentioned in TFA's README.

Re: First C compiler ported to GCC

#56

Post by pjmlp »

MaxBarraclough wrote: post #44
st_goliath wrote: post #40

Earlier quoted context omitted.

So you expect to compiler to give you style points for your code? To be clear: it isn't just coincidentally identical behaviour, it is defined by the standard to be equivalent.

Yes, compilers should warn on indisputably poor style, even when program behaviour might still be correct. This is helpful to the programmer, who probably didn't intend to write their code that way. Fortunately compilers already do this. GCC will warn you about unused variables, for instance.

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.

To this day, the best result regarding adoption of such tooling places it around 11%.

I wonder how much education we need to keep fighting for adoption.

Re: First C compiler ported to GCC

#57

Post by pjmlp »

st_goliath wrote: post #52
yakubin wrote: post #47

Earlier quoted context omitted.

Most compilers will warn about misleading indentation. This is misleading indexing. A program containing misleading indentation is also standards-compliant, but that's completely irrelevant when talking about what code should trigger warnings.

Misleading indentations, unused variables, unused goto labels and the like are a quite good indicator that there is something wrong here. The thing we are talking about here is issuing warnings for "but that's not how we usually do it". When you add a new warning to a C compiler, you will break build processes all over the planet that have "-Werror" turned on and/or have management that insists on warnings being addr…

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.

Re: First C compiler ported to GCC

#58

Post by mschuster91 »

charcircuit wrote: post #54
mschuster91 wrote: post #42

Earlier quoted context omitted.

I understand why that example works but I struggle finding a valid use-case, aside from code golfing...

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.

Re: First C compiler ported to GCC

#59

Post by sramsay »

aap_ wrote: post #29
onei wrote: post #23

Earlier quoted context omitted.

The very first B compiler was written in BCPL by Ken Thompson. B later became self-hosting, i.e. the BCPL compiler compiled the B compiler, but this had another set of challenges due to the extreme memory constraints. It was an iterative process where a new feature was added such that it pushed the memory limit and then the compiler was rewritten to use the new feature to bring the memory usage down. C was heavily in…

The first B compiler was actually written in TMG, and once it was bootstrapped that way in B itself. BCPL was only the inspiration for the language.

Wow, TMG was a new one for me. From the Wiki article on it:

"Douglas McIlroy ported TMG to an early version of Unix. According to Ken Thompson, McIlroy wrote TMG in TMG on a piece of paper and "decided to give his piece of paper his piece of paper," hand-compiling assembly language that he entered and assembled on Thompson's Unix system running on PDP-7."

We are not worthy, friends. We are not worthy.

Re: First C compiler ported to GCC

#60

Post by st_goliath »

pjmlp wrote: post #57
st_goliath wrote: post #52

Earlier quoted context omitted.

Misleading indentations, unused variables, unused goto labels and the like are a quite good indicator that there is something wrong here. The thing we are talking about here is issuing warnings for "but that's not how we usually do it". When you add a new warning to a C compiler, you will break build processes all over the planet that have "-Werror" turned on and/or have management that insists on warnings being addr…

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 around if that's really what you want to do here. I think this is perfectly reasonable.

However, in the mean time, a lot of people have decided to adapt a coding style where you always put the constant or literal on the left hand side if possible, to avoid this issue. In theory, the gcc developers could in addition also have opted to issue warnings for comparisons if the left hand side is an lvalue and the right hand side a constant or literal, that you might want to flip it around. Thus enforcing a "safer coding style" through compiler warnings.

I'm arguing that the former is a perfectly reasonable thing for a compiler to do, while the later isn't.

Post reply on HN