Teammate just spent two weeks tracking down the source of some floating point differences at runtime, after removing unused headers...

```
double foo (float bar) {
return sin(bar);
}
```
You'll get different results based on whether you included math.h or cmath first...

https://godbolt.org/z/zThqenPrj

christ, you even get different results between C and C++ modes with the first example...

@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

@keithp that's what I thought, too!

@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

@palmer Please bookmark https://www.open-std.org/jtc1/sc22/wg14/www/projects.html, then _never_ refer to the C11 draft again. :P

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

@palmer the latest public 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...

@keithp @pinskia @amonakov I just want _Float128 (to my knowledge clang still lacks). So much old garbage code portability issues stemming from long double.

@keithp @pinskia @amonakov though our hardware is increasingly using smaller than 16b floats (multiple fp8 representations). Compiler and library vendors cant keep up with the ML peoples demands for smaller and more bizarre floating point representations.

@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.

@keithp @pinskia @amonakov can we not just get rid of wchar_t? I've never targeted windows...

Perhaps I should round up folks (many in this thread) with scars from writing C for so long, describing the warts, and what C might look like if we did it from scratch today. Always a fun experiment, no matter how idealistic and non-pragmatic...

@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.

@pinskia @keithp @amonakov maybe for April fools we could publish patches for both toolchains? The other fantasy I have is the toolchain vendors forming their own committee, a la the WhatWG/W3C schism. I have _weird_ fetishes

@pinskia @keithp @amonakov on this weeks episode of "C programming language features Survivor...sorry comma operator, you've been voted off the island. "

"And introducing a new spin off series, from the same producers of C programming language features Survivor, POSIX Mistakes Survivor! Who will be voted off this week? Will it be pthread cancellation, <regex.h>, or shm memory leaks?"

@pinskia @keithp @amonakov or maybe just a blog post collection of "what's your least favorite feature(s) of C" sampled from salty dogs would be highly entertaining, and explain why our civilization eventually fell to archeologists digging up our bones. "Wow, such primitive peoples. Raw pointers? No wonder they _all died_!"

@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?