@llvm, C's sin(double) vs. overloaded C++ sin()?

@llvm implicit promotion is rarely fun ... -Wdouble-promotion might be useful to flag some of them.

Sometimes I wish/wonder what it might take to have them off/disabled OOTB.

@llvm Looks like that C/C++ difference is a feature? The overloads are called out as a difference in 26.8.9 of the C++11 draft, they're not in the C11 draft. Not 100% sure there, as cppreference is claiming there's a macro override in C99 that I can't find (flavor 7 of sin() in https://en.cppreference.com/w/c/numeric/math/sin.html ).

@llvm I'm not surprised there was a difference, but I am surprised that using the C header resulted in a call to sinf while the C++ header called sin. With C, I thought you had to use tgmath.h to get that behavior...

@llvm this is kinda of expected.
cmath does not pull in the C++ overloads into the global namespace from std namespace.
While math.h does.
But the underlying glibc (I think most libc do it this way except maybe Solaris's) math.h has in the global namspace the function sin.

There is/was a library defect report about this against the C++ std even. https://cplusplus.github.io/LWG/lwg-defects.html#456

@llvm I tried using tgmath.h and comparing C and C++. With tgmath.h, C calls sinf and C++ calls sin. What?

https://godbolt.org/z/4z985Y9nf

@llvm which one do I read? That where I got the C11 draft...

@llvm OK, so it's just C11 being a trash spec? I was specifically looking back that far to try and see the older version, and it looks like stuff has been moving around in the newer specs

@keithp @llvm and if you pass -stdlib=libc++ to Clang, the behavior changes again.

The "gotcha" is that including math.h in C++ mode actually includes libstdc++'s wrapper math.h that brings overloaded std::sin into the global namespace. Hence:

include <cmath>: sin refers to C's sin(double), not std::sin
include <math.h>: sin refers to generic std::sin

@amonakov @keithp @llvm

See https://cplusplus.github.io/LWG/lwg-defects.html#456 for some of the history on this mess.

@pinskia @amonakov @llvm I'm sure glad I don't use C++ in my own development work...

@llvm @pinskia @amonakov yeah, C's whole implementation defined types is such a disaster. We don't need choice about representations in 2026, we need certainty which leads to portability and stability. There should only be explicitly sized types for both ints and floats, wchar_t should always be UCS-4/UTF-32, etc.

@llvm @keithp @amonakov I can think of ways of doing this as an option to GCC/clang as nice subset that would "kick" out the warts like wchar_t. And even try to make char8_t (and char16_t) as seperate types rather than typedef's for C (C++ it is already a seperate type).
And then for C++ do a similar subset like kick out wchar_t too.

I know it won't be C or C++ any more but it might be a decent subset that many folks would adopt it.

@llvm @keithp @amonakov

order of evaluation of arguments.

@llvm @pinskia @amonakov I dunno, it's a tough race between implementation-defined behavior and undefined behavior. Both are unpardonable defects of any language, but the C standard embraces them as features?

@llvm Huh, you are assuming it is the *users* in WG14 that prevent improvements? Getting rid or even deprecating old stuff is mostly vetoed by vendor representatives.

@llvm The typical argument is: "If we deprecate this, customers would expect us to warn about it by default, but then we would warn about too much old code" or "if we make this a constraint violation instead of UB, this we want to make this an error and not warning (even if allowed by the standard), but then this breaks too much code". Another one is: "we fear this might cost us in 0.1% in performance in SpecINT (but we don't really know)"

@llvm To be fair, the users often have no clue about how a compiler works, what they want (everybody has different idea and wants t see some shiny feature seen in another language), and vendors are also rightfully worried that we might vote in something crazy.

@llvm A pure vendor committee would basically just do nothing, rubber stamp everything as new ISO standard once in while, and if there is some divergence or bugs, just declare this aspect undefined behavior.