Hacker News Reader

Comment by matheusmoreira | Hacker News Reader

Compiler optimization is really annoying sometimes. It's allowed to assume that functions with the same name as standard library functions behave according to standard. They'll swap out printf calls for puts if they don't have a format. The compiler just knows it can do that. Sure, it optimizes things but it gets to the point the code no longer reflects what's written on the source file. Try to hook into printf and it won't work because it's not actually calling printf.

Even on freestanding environments they can and will generate calls to memcpy and memmove. That's insane...

View on HN

Why is that a problem? (That's a serious question. I'm not suggesting that it isn't a problem. Apparently it is for you.)

If I write printf("Hello, world\n"), all I care about is that those characters are written to the standard output stream when I run the program -- and that's all the language standard specifies. I rarely even look at the assembly or machine code.

As someone else mentioned, "gcc -fno-builtin" inhibits optimizations like this. Other compilers are likely to have similar options.

Because it's surprising and breaks our expectations. The author of this article clearly expected a call to printf to be present in the generated code.

> all I care about is that those characters are written to the standard output stream when I run the program

Sometimes people care about a lot more. Such as the ability to hook into a specific function or ensuring the compiler doesn't generate calls to certain functions.

> that's all the language standard specifies

The author clearly cared about the undefined behavior. He had a mental model of what would happen that was perfectly reasonable. It was constantly invalidated by the optimizer.

> I rarely even look at the assembly or machine code.

I do. It's very jarring when you write some code and the compiler deletes some of your calls and reorders the rest. It can really complicate debugging sessions.

> gcc -fno-builtin

Yeah, that's become a standard flag for me. Just checked the documentation and it turns out it's also implied by -ffreestanding which is a better language than hosted C anyway just because it gets rid of all the libc cruft.

That's exactly why we have specifications and standards - so that you don't have to guess and build mental models on flimsy assumptions, and know exactly what to expect.

The standard leaves so much stuff undefined or implementation defined there's no way to fully understand what's going on anyway. The only mental model you can form is of the very limited non-existent abstract machine, anything else you have to guess or go to great pains to avoid. It just isn't very useful to think in those terms, so many intuitions just aren't possible. Turns the language into this huge minefield.

I've given up on that. Standards don't compile code so they don't really matter in the end. I'm interested in what my compilers do and the code they generate. I've found I can just tell them to define the formerly undefined behavior, significantly improving the language as a result. No strict aliasing, forcing signed integers to wrap around as you'd expect them to, etc.

It sounds like what you really want is a high-level portable assembler. Which, to be fair, is one of the niches that C has occupied... but I'm not convinced it's optimally designed for that in general, even leaving UB aside.

But back in DOS days, there was something called Sphinx C--: https://bkhome.org/archive/goosee/cmm/c--doc.htm. A modern cross-arch reincarnation of that could be interesting.

> high-level portable assembler

Yeah.

More precisely, what I want is something that:

1. Gives me simple native code ELFs

2. Containing no symbols other than the functions I defined

3. That can interface directly with the Linux kernel with zero dependencies

If I bend C enough it turns into something resembling that. Freestanding C, a couple flags to fix the language and the compiler's inline assembly to fulfill the 3rd requirement. I agree that it's not perfect for the role but C compilers are way too important for me to simply disregard them and look for or invent a new language. I'd be giving up too much.

I wish the newer C standards took the time to define previously undefined behavior instead of adding even more cruft to the standard library. C11 is just the opposite of what I wanted.

Reducing UB also reduces optimization opportunities, and these days, outside of embedded, C (or C++) is usually used because it's fast - there are better options if that's not a concern. So I don't think that the base C standard will ever do that. But there can be standards derived from it, which provide more rigorous guarantees at the cost of perf.

Then you have embedded, where the norm is either gcc (which loves to optimize away UB), or bespoke compilers produced by the hardware manufacturer that are usually full of weird bugs in any case.

Given that, is C really that important? I can see the ability to parse C headers as somewhat useful for the sake of interop, just so you could use all the libraries (and not just syscalls); but aside from that?

There is no "undefined behavior" in the sense that the C standard uses that term. The choice of which function to generate a call to in the generated assembly or machine code is not "behavior".

The way I think of it is that a C program specifies run-time behavior (which consists mostly of I/O). Any generated code is just a way to achieve that. C is not some kind of assembly language. The standard says nothing about CPU instructions or registers.

If you want to use C source code as a way to generate specific assembly or machine code, you'll have to go beyond what the language standard guarantees. If you need to do that, and you have an implementation that helps you with it, that's great.

I wonder if there's enough demand for a language that's independent of the target processor but still guarantees that a source call to a given function actually results in a call to that function, that a "+" operator results in a single addition CPU instruction, and so forth. It's not something I'd have any use for myself, but that doesn't mean it wouldn't be valuable. C isn't that language, but something similar to C might be.

Do you also expect `sqrt(a)` to be `call sqrt` and not `sqrtss xmm0`?

No. I expect that from I/O functions.

How is it different? Why do you draw the line at I/O function?

Because it doesn't really matter how the program calculates mathematical functions as long as the result is correct. Whether it's a function or an instruction, it's inconsequential.

I/O on the other hand is a lot more interesting. They're a very common source of undefined behavior, bugs and interception via custom shared objects. I'd rather the compiler touched them as little as possible. Actually I'd rather not use them at all. I find system calls to be much more ergonomic.

What about datetime, random, system, etc?

They're all system calls that are better served by using operating functions directly. I'm not sure how the compiler could possibly optimize those away though. Maybe the random function could become a very untrustworthy instruction?

Random number generation generally isn't handled by system calls. It's just computation. (Some languages do provide support for hardware [pseudo-]random number generation. C doesn't.)

More generally, using system calls directly for things like getting the current time makes sense only if you don't care about portability.

C can support both portable and non-portable code. Both are important.

I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. I sympathize with your situation, but it's not one that most programmers share.

> I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements.

Definitely seems that way to me as well. Still, if I bend C enough it turns into something that's almost what I want. I just wish GCC had a couple more flags to control code generation in these surprising cases.

For me, it doesn't matter whether printf("hello\n") works via a call to printf or a call to puts. If those 6 characters I specified are written to standard output, I don't care how it was done.

Of course I care if I want to use the value returned by printf, but if my code uses that value the optimization isn't performed.

I think the semantic gap between assembly language and C is much wider than a lot of people realize. I wonder if a language somewhere in the middle of that gap would be useful to some people. (It probably wouldn't be useful to me.)

> Do you also expect `sqrt(a)` to be `call sqrt` and not `sqrtss xmm0`?

Of course. Who else is going to set errno when I pass negative a number?

So the compiler actually can't optimize because of legacy errno cruft? That's hilarious...

The compiler respects the C standard by default. According to it, puts() is the same as a printf() in some conditions, but sqrt() is not the same as the instruction.

If you don't like C, you can use a dialect of it by setting some flags: -fno-math-errno if you want to optimize sqrt anyway or -fno-builtin if you don't want the compiler to replace functions calls

I like C for the most part. I don't like the standard library. It's got stuff like errno, a thread local global variable, and that's just the simplest problem. Freestanding C turned out to be a far better language just because it has no legacy cruft weighing it down.

> -fno-math-errno

That's interesting, didn't know about it.

Ok, so make the question one of `call sqrt` vs `sqrtss xmm0` + a test that sets errno in case of negative then?

Or even simpler: do you demand that `x = sqrt(4)` entails emitting code that calls `sqrt`?

Nobody has to, if you pass it an unsigned int. Would you still expect it to be a function call then?

Reply on news.ycombinator.com