This is not a rant, but a well laid-out description of something a widely used software ran into as a result of a change in the compiler they use.

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.

It's not well laid out. The examples are malformed/illegal and the ifdef thing is stupid.

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

> The author admits to not being a C undefined behavior expert

At this stage, I would seriously doubt the credentials of anyone who claims to be a C undefined behaviour expert. Saying "I'm not a C UB expert" is just a realistic acknowledgement that UB is hard and we will get it wrong at some point without realising. The approach of having an automated tool tell you when UB is present is very sensible.

The ifdef thing certainly isn't "stpuid". It's not good design, you wouldn't design it that way if you made libcurl from scratch today, but it makes sense as a solution to the problem of, "we can't change the type of CURL* in the public API, but internally, it ought to be defined as a pointer to a struct". If it was well-defined behavior, it would probably have been the best solution possible given the constraints.

And apparently worked the last 28 or so years on loads of other machines (I think the question would be where doesn't curl run)?

Casting function pointers like this can break Emscripten [1]. In libxml2, I fixed all these issues 7 years ago. It can be painful, but "it worked for 28 years" is not an excuse.

[1] https://emscripten.org/docs/porting/guidelines/function_poin...

I believe AIX C++ name mangling includes function argument type information (with CV qualifiers!) so this is a real-world case where this does actually break. I suspect curl does not compile with the C++ compiler though.

So does the Itanium ABI (which is what most people would think of as the normal/standard/usual C++ ABI):

  $ c++filt
  _Z1fPFvPcE
  f(void (*)(char*))

But I'm struggling to understand how this would cause things to break.

I guess only if you directly expose C++ APIs in DLLs, which is a bad idea anyway.

It's literally the opposite of "works on my machine" because it's in curl (which is most likely the single most widely deployed code base in the world).

How would you implement objects and inheritance in C without function casts? CPython certainly uses these casts.

dlysm() even relies on a (void *) cast that is not C standard compliant.

C is useless for certain applications with this "undefined behavior".

That is the thing, people keep treating it as a portable macro assembler, when it stopped being so decades ago, and those folks haven't yet got the memo.

Use a generic function signature that takes in a `void*`. Inside the specialized function bodies, cast the void* to an `actual_type*`, then dereference.