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

A convenient untruth: Array notation in C is a lie

blog.feabhas.com

Post reply on HN
Print view View original

11–20 of 176 posts

Re: A convenient untruth: Array notation in C is a lie

#11

Post by MichaelBurge »

I'd be careful about assuming that C code run on a human interpreter behaves similarly to C code compiled by a modern compiler. For example, string literals probably don't actually have to exist in memory anywhere, but could arise implicitly from the control flow of your program. A compiler could probably turn:

    char *x = "abcdefghijklmnopqrstuvwxyz"
    printf("%s", x)
into something like:

    for (int x = 'a'; x
Maybe when your program thinks it's accessing the 42nd element of that array, it's actually accessing some function of (the number of clock cycles in the CPU's counter, n unrelated code segments XOR'ing into a memory location, the executable's exact binary output) and the compiler has conspired to make these calculate to what that string's value would've been in an imaginary virtual machine to save 2 bytes(or because they're cached).

Sounds like a good DRM scheme actually.

And who says pointers are to RAM addresses? Maybe the compiler statically notices that the pointer's target stays strictly between 'a' and 'z', and decides to use a simple 26-value counter. Depending on how you debug a program compiled by a sufficiently smart compiler, pointers could point to RAM addresses only when you're looking at them.

That for loop you thought you wrote? Well, your program accesses different parts of the result at different times, so it scattered it all over your program so it's lazily computed. The loop counter or pointer never actually exists or takes on any value.

You can't be sure any of it exists unless you add logging or inspection. The whole program could be a lie, cleverly calculated to mimic the one you really intended.

Re: A convenient untruth: Array notation in C is a lie

#12

Post by bluetomcat »

spacelizard wrote: post #8

Brings back fond memories of the first time I learned C, when I really had to dig into what the difference was between storage durations (auto/stack, dynamic/heap, static, thread local). It makes it increasingly important to think about when an object is going to be stored, and for how long. To me this is still a really useful concept that most high-level languages seem to have all disregarded in favor of extremely e…

C has a really simple model with regard to storage durations, but the usage/omission of the respective keywords (static, extern, auto) is what makes it hard for beginners, IMO.

`static` means different things at file scope and at block scope, `extern` is redundant most of the time (except when linking to an object from another unit), `auto` is 100% redundant and is a leftover from the days when `int` was implied for every declaration.

Re: A convenient untruth: Array notation in C is a lie

#13

Post by coldtea »

hardlianotion wrote: post #4

Is this article a sign that C has fallen out of mainstream use?

Four answers:

No, C (and C++) is used as much as ever. HN echo chamber aside, Rust and/or Go haven't made much of a dent.

No, we had such articles for decades.

No, it's just an article that points some issues with C, like exist for every language and environment (e.g. tons of articles on JS shortcomings). No correlation whatsoever with such an article and the language falling out of mainstream use.

No, this is a bizarro question. It's an article by single person, not some general trend.

Re: A convenient untruth: Array notation in C is a lie

#14

Post by ordu »

These facts is not a lies. They are inconviniences which one can see looking on C from perspective of higher level language. But if you learn how to program with assembler before studing C, than all these facts would look like obvious and convinient syntactic sugar.

Maybe in C++ these facts become inconvinient, because of C++ pretending to be higher level language than crossplatform assembler. But if it is a problem, it is not problem of C, it is problem of C++.

Re: A convenient untruth: Array notation in C is a lie

#15

Post by dom0 »

MichaelBurge wrote: post #11

I'd be careful about assuming that C code run on a human interpreter behaves similarly to C code compiled by a modern compiler. For example, string literals probably don't actually have to exist in memory anywhere, but could arise implicitly from the control flow of your program. A compiler could probably turn: char *x = "abcdefghijklmnopqrstuvwxyz" printf("%s", x) into something like: for (int x = 'a'; x Maybe when…

> The whole program could be a lie, cleverly calculated to mimic the one you really intended.

The standard has a similarly convoluted way of saying that, in a nutshell, C compilers are permitted all optimizations under the as-if rule. (§ 5.1.2.3)

Re: A convenient untruth: Array notation in C is a lie

#16

Post by dagw »

coldtea wrote: post #13
hardlianotion wrote: post #4

Is this article a sign that C has fallen out of mainstream use?

Four answers: No, C (and C++) is used as much as ever. HN echo chamber aside, Rust and/or Go haven't made much of a dent. No, we had such articles for decades. No, it's just an article that points some issues with C, like exist for every language and environment (e.g. tons of articles on JS shortcomings). No correlation whatsoever with such an article and the language falling out of mainstream use. No, this is a biza…

No, C (and C++) is used as much as ever

Is this really true, especially for C? Lots of things that used to be done in C is today done in C++ and lots of things that used to be done in C++ is today done in Java or C#.

Re: A convenient untruth: Array notation in C is a lie

#17

Post by dagw »

GoToRO wrote: post #9
hardlianotion wrote: post #4

Is this article a sign that C has fallen out of mainstream use?

If by "mainstream use" you refer to applications then maybe yes. If you refer to embedded use, for sure not.

Even in the embedded world I'm seeing more and more C++ these days.

Re: A convenient untruth: Array notation in C is a lie

#18

Post by TickleSteve »

MichaelBurge wrote: post #11

I'd be careful about assuming that C code run on a human interpreter behaves similarly to C code compiled by a modern compiler. For example, string literals probably don't actually have to exist in memory anywhere, but could arise implicitly from the control flow of your program. A compiler could probably turn: char *x = "abcdefghijklmnopqrstuvwxyz" printf("%s", x) into something like: for (int x = 'a'; x Maybe when…

You're describing a general problem in general terms...

Does a program that has no side effects even exist?? ooOOOoh, spooky....

BTW, yes I know what you're getting at... optimisers are allowed to perform any transformation as long as they're semantically equivalent. This applies to all languages.

Re: A convenient untruth: Array notation in C is a lie

#19

Post by baydonFlyer »

dagw wrote: post #17
GoToRO wrote: post #9

Earlier quoted context omitted.

If by "mainstream use" you refer to applications then maybe yes. If you refer to embedded use, for sure not.

Even in the embedded world I'm seeing more and more C++ these days.

True C++, especially with C++11/14 is growing, but based on all the recent studies (by people like embedded.com) C is still a long way ahead of C++ in the embedded space.

Re: A convenient untruth: Array notation in C is a lie

#20

Post by bluetomcat »

dom0 wrote: post #15
MichaelBurge wrote: post #11

I'd be careful about assuming that C code run on a human interpreter behaves similarly to C code compiled by a modern compiler. For example, string literals probably don't actually have to exist in memory anywhere, but could arise implicitly from the control flow of your program. A compiler could probably turn: char *x = "abcdefghijklmnopqrstuvwxyz" printf("%s", x) into something like: for (int x = 'a'; x Maybe when…

> The whole program could be a lie, cleverly calculated to mimic the one you really intended. The standard has a similarly convoluted way of saying that, in a nutshell, C compilers are permitted all optimizations under the as-if rule. (§ 5.1.2.3)

The "canonical" mental memory model of C (globals in data/BSS, locals on the stack, memory is a big array, code and data are the only artifacts) may be utterly useless when reasoning about the performance of a program, but helps the programmer greatly when approaching a problem.

The language was designed with these things in mind, no matter how much more sophisticated compilers and hardware have become, and no matter how much language lawyer fetishists frown on you for saying "this is on the stack" instead of "this has automatic storage duration".

Post reply on HN