Intuitively, I would say that this is actually undefined behavior (it would probably be difficult to expose a wrong behavior in practice though).
In C specs, I found 6.5.2.2, paragraph 9:
> If the function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function, the behavior is undefined.
We might discuss whether
void (*)(char *)
void (*)(void *)
void target(void *ptr) {}
void (*name)(char *ptr) = target;
initialization of ‘void (*)(void *)’ from incompatible pointer type ‘void (*)(char *)’
Same for:
void target(char *ptr) {}
void (*name)(void *ptr) = target;Emscripten breaks if you cast function pointers: https://emscripten.org/docs/porting/guidelines/function_poin...
void (*name)(char *ptr);
typedef void (*name_func)(char *ptr);
void target(void *ptr)
{
printf("Input %p\n", ptr);
}
char *data = "string";
name = (name_func)target; // Illegal: casting fn that takes void* to a fn that takes char*
name(&data); // Illegal: passing a char** into a function that takes char*
/* declarations */
void qsort(void *lineptr[], int left, int right,
int (*comp)(void *, void *));
int numcmp(char *, char *);
/* the offending line */
qsort((void **) lineptr, 0, nlines-1,
(int (*)(void*,void*)(numeric ? numcmp : strcmp));I assume this is just a typo in the article. He probably meant `name(data)`.
The above code still doesn't compile in C because C complains about the function signatures being incompatible, even though the only difference is the argument type which itself is 'equivalent' in C - which I guess could be interepreted as an edge case in the C spec? (IMHO the function prototypes should actually be compatible).
Compatibility is essentially about ABI: https://en.cppreference.com/w/c/language/type#Compatible_typ...
The C standard is quite loose about pointer requirements. Conversions between data pointers or between function pointers are allowed, but conversions between each other are not guaranteed. You can read the nitty gritty here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
POSIX defines stricter requirements for pointers than the C standard. All pointers are compatible, so they have the same size and representation, and conversions between function pointers and void* are explicitly allowed.
In C++ any pointer is also implicitly convertible to a void *, it is the reverse implicit conversion that is prohibited as it is not safe in the general case.
For consistency C++ should also prohibit implicit narrowing conversions (e.g. int to short ); I guess this was thought to break too much existing code and it is generally safer than a pointer conversion (although potentially lossy the behavior is fully defined). Many compilers will warn about it, and narrowing conversions are now prohibited in braced initialization.
The typedef struct trick, is very common idiom that creates _more_ safety, not less. All reasonable compilers should (and do) support this. It is sad that the ISO standard is not in line with reality at all times. (I say that as a member of the wg14 and the UB study group)
I Recommend Daniel keep his typedef struct definition, and then have an ifdef to revert to the void definition for when Clang does its UB sanitizer. While checking for prototype discrepancies is a very good thing to automate, Clang should add an exception for this.
Given:
typedef struct foo Foo:
Foo * createFoo();
void useFoo(Foo * foo);
Foo * foo = createFoo();
void * vp = foo;
useFoo((Foo *) vp);
void (*)(void *) vf = (void (*)(void *)) useFoo;
(*fv)(vp);Example:
Lets say you have a function that takes a pointer to a 32 bit integer.
void my_function(int x)
But in an other file you declare it as a function taking a 32 bit float, and call it:
extern void my_function(float x); ... my_function(&my_float);
This is very likely to work in almost all implementations. float and int have the same size and same alignment requirements, but the standard may still say its UB. So it is technically UB, but may be relied upon in practice.
Since you have experience in this area, do you know how likely it is that something like this could be resolved? I.e., if someone proposed "just make this defined", how likely would the C standards body be to agree and do so?
In the bad old days, such cases were very common. I think complaining about it is a part of the process that slowly resolves it.
This category of we call ”usless UB” are things that wont help optimizeayions, and all major compiler have to support beacause if they dont, their users complain too much, can be relied on.
Unfortunately its very hard for the average use to know what UB can be relied on (there isnt much).
I think the fact that it turned out that he was wrong (and UBsan was right, as usual) is a great testament to the shortcomings of C.
Lots of people - both inexperienced and very experienced - celebrate it for being "simple" and "close to the hardware", but the truth of the matter is that it is precisely not close enough to the hardware for people who _know_ what the hardware is doing to be able to do what they expect, and it's too close to the hardware to be able to be able to ignore it.
Lots of experienced C programmers (and - guilt by association - C++ programmers as well) run into UB because they have clear expectations of the compiler. I.e., they know what the compiler should generate, more or less, and C is just a convenient notation. But compilers don't live up to those expectations, because they don't actually compile your code for the hardware. They compile it to the virtual machine abstraction defined by the standard, which very often works differently from any real architecture, and then translate that into machine code. Even though there is basically a single set of semantics that every single "relevant" (mainstream) architecture implements. This is a holdover from when C had to target architectures that are 100% irrelevant today.
Everybody's favorite example is signed integer overflow. In both x86-64 and ARM64, that just works - two's complement is the only relevant implementation, so there's no issue. But `int` in C and C++ is not that.
Almost every single common UB pitfall has reasonable behavior at the assembler level for every mainstream architecture, and almost every single niche architecture.
C gives you the illusion of being close to the hardware, but in actual reality the hardware is several steps removed, so if you want to leverage your knowledge of the hardware, calling conventions, assembly, or other low-level details, you have to go out of your way to work around the C standard.
(Aside: We need new languages to tackle this, and I coincidentally happen to like Rust. Lots of people coming from C or C++ are irritated and frustrated by Rust, but 99% of the time it's because Rust gives you a compile error where C would give you UB. This is one example of that out of thousands.)
Many folks will complain about anything that breaks their beloved illusion that C is a fancier macro assembler, except even proper macro assemblers have less UB than regular C.
Signed integer overflow is something were I personally like that it is UB, because I can turn on UBSan and find overflow bugs. If it were defined to wrap-around I could not do this.
(External linkage) functions, and their callsites, are quite special as they straddle the boundary between actual machine and virtual machine.
The calling convention makes fairly strict requirements of what that must compile down to, since caller and callee could be dynamically linked objects compiled by different compilers or even entirely different languages.
If you define a function that takes a void* parameter it will read a pointer from the RDI(?). If you pass a char* it will pass the pointer in that same register.
Now it must be said that if the compiler can see both the definition and call, then it's free to do whatever it wants e.g. inline or something.
But yeah it's a bit complicated?
I postulate that almost all UB in the wild comes from the Standard diverging from (often very reasonable) expectations, and I see that as a big problem with the standard, at least as long as compilers can't reliably detect the problem at compile-time. (And yes, C++ is even more problematic here.)
I think one of the reasons Zig exists is that it contains far fewer surprises. The reason Rust exists is that it does a much better job at preventing and containing such surprises.
Now, C++ programmers, were you consulted about these costs? Herb insists they're "unacceptable" but he provides no further information as to what the cost actually was, or who decided whether that cost was acceptable, much less how this could generalize across a wide variety of domains and platforms.
What's Herb's answer? You might hope that Herb would say OK, we'll provide wrapping for these types by default, it's not checked arithmetic but at least it's not UB. Nope.
They've got undefined behavior: The standard imposes no requirements. Anything can happen. Assume the worst.
They've got unspecified behavior: Only covers behavior caused by an unspecified value or where the standard provides multiple choices, where the implementation need not document which choices are made in which situations.
They've got implementation-defined behavior: Unspecified behavior that the implementation must document.
They don't have a category for "Undefined behavior but the implementation must document". A lot of what is currently undefined behavior could better be put into this category, if it existed.
For my main software project, which is some numerical software for magnetic resonance imaging, this adds 12212 checks and the optimizer reduces them down to 3803. But I haven't done benchmarking yet, but I would guess that for most software it would not matter.
Of course you can define your own checked integer types, using inline assembly to check the overflow flag where available.
#if defined(BUILDING_LIBCURL)
struct Curl_easy {
…
}
#else
struct Curl_easy;
#endif
typedef struct Curl_easy CURL;
struct X {};
void use_x(X*);
using F = void(void*);
void bar(F* fn, void* y) { fn(y); }
template<class T, auto fn>
void trampoline(void*arg) { return fn(reinterpret_cast<T*>(arg)); }
X x;
bar(&trampoline<X, use_x>, &x);
edit: I'm not advocating that this being UB is fine. I don't expect compilers to exploit this for optimization, because so many projects rely on this working. There might be room to extend compatible function types to make this defined.
This seems to be the obvious solution and how most libraries define their opaque handles. It doesn't break a guaranteed API and it doesn't break the ABI any more than than only using it when building the library - and you can check that it doesn't break the ABI on any platform where you want to guarantee ABI stability.
Anyway, if folk are curious there are many platforms where not only can the representation of `void()(void)` and `void()(char)` be different - even if pointing to the same function - but the representation of even just the data pointers void* and char* may not be the same, again while pointing to the same memory.
For example, on platforms with pointer authentication function pointers are generally (I would say "always" but in principle it can be avoided) signed, and in some configuration the type of the function is incorporated into the function. Calling the function pointer requires authenticating the pointer, and authenticating the pointer requires that the call site agrees on the type of the pointer because otherwise the signature fails.
Absent actual pointer auth hardware you could imagine someone implementing this as some kind of monstrosity like this (very hypothetical, unpleasant, and footgun heavy) horror:
#define SIGN_FPTR(fptr) (typeof(fptr))(((uintptr_t)fptr)|(MAGIC_HASH(stringify(typeof(fptr)) << some_number_of_bits))
#define AUTH_FPTR(fptr) (typeof(fptr))(((uintptr_t)fptr)^(MAGIC_HASH(stringify(typeof(fptr)) << some_number_of_bits))
In principle a pointer auth environment could apply this type discrimination logic to data pointers as well, but I'm unaware of any that do so implicitly. But if a platform did do so, then the incorrect type of the parameter would mean you would fail inside the function, if you were able to call it (say if you weren't using a function pointer, but had mistyped the prototype).
Similarly, in other environments, the pointer may be directly aware the type being referenced, and I believe that CHERI supports this, in which case even if you could call the function pointer when attempting to read the pointer I believe it would fail.
Having got here, you might be saying "but hang on C says void* and char* are the same", and we go all the way back to my first sentence where I said "are implicitly convertible" :D
On plenty of systems casting from one pointer type to another is an entirely source level feature and once lowered is completely invisible. But in the environments we're discussing
(Type1*)pointerToType2
But the important thing is the C does not say they are the same thing, just that the conversion is automatic, just like numbers and bools, or numbers and bools in JS, or numbers and strings in JS, or objects and strings in JS, or nothing and strings in JS, or .... :D
I did try to simplify things as well rather than focusing on specific language technicalities, because just going into arbitrary amounts of technical detail didn’t seem like a good way to explain things, and I’ve found can result in people thinking you’re focusing on those “technicalities” rather than “real” issues, without understanding the technicalities are the root of the “real” issues.
The #ifdef they had in place was a bit hackish, but I wouldn't call it abuse. It is a typical construction for C to do stuff like that which in general isn't without risk, but they have used it without any problems for years. The whole point of the blog post is to start a discussion whether sth. like this should rightfully be flagged as "unexpected behavior" or not.
The author admits to not being a C undefined behavior expert and yet acts like they might know better than a tool made by such experts.
Looking up the rules and verifying the shown snippets takes at most 30 minutes at a leisurely pace, the author could have saved themselves the embarrassment.
I'm not going to write a blog post about how I didn't expect a color spectrometer pointed at the sky to say "BLUE" because I thought it might have been purple, "although I'm not an expert in wave lengths".
[1] https://emscripten.org/docs/porting/guidelines/function_poin...
dlysm() even relies on a (void *) cast that is not C standard compliant.
C is useless for certain applications with this "undefined behavior".