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?
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
> -fno-math-errno
That's interesting, didn't know about it.
Or even simpler: do you demand that `x = sqrt(4)` entails emitting code that calls `sqrt`?
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.
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.
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.
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.)