stdlib: Support compiling with tinyc by omitting compat qsort code

[imp]

Summary

TinyC doesn't support the .symver assembler directive. Add a generic way
to signal this and use that not to define sym_() macros that use
it. Only use the sym_* macros in headers when they are defined (which
currently is only for the qsort_r compat code. Not supporting this for
tcc is fine: It's an edge case for legacy binaries / code anyway which
isn't relevant to tinyc.

[kib]

This is fine functionally, but wouldn't we want some symbol defined in cdefs.h that indicates the lack of symver support?

[imp]

Ideally, we'd just not define sym_compat and omit the first symbol that uses it when sym_compat isn't defined. That's the most straight forward thing to do. But that review got mired down and I abandoned it and lost the branch locally somehow. I'll rework this to do that, though.

[imp]

Move to the more preferred way to gate this stuff.

[imp]

remove extra change

[brooks]

At some point we should probably make triggering this code produce a warning, but that's for another change

include/stdlib.h

343

gratuitous new parentheses

[brooks]

I think the C++ case will now expand, but fail to link

[imp]

tinyc doesn't support cplusplus, so this is a nop for that. However,
some future compiler might support C and C++, but not support symver, so
go ahead and make this future proof.

[imp]

In D45651#1041634, @brooks wrote:

I think the C++ case will now expand, but fail to link

cplusplus won't be defined for tinyc, so this will only be an issue if tinyc were to grow C++ support, which seems very doubtful.

But I'll make it fully generic in case there's other compilers in the future that do have C and C++ but no symver support.

include/stdlib.h

343

Fixed while you were reading it :)

[kib]

include/stdlib.h

356

Note not related to the review at hands: compar should be extern "C"

[imp]

include/stdlib.h

356

Can you help me understand your comment? I thought that extern "C" is for name mangling and overloading purposes only. Neither of those apply to a function pointer. I don't even know how to do that syntax in C++.

[kib]

include/stdlib.h

356

extern "C" is definitely not for overloading. It de-facto defines the function ABI, which includes the name mangling, and potentially different calling conventions between C and C++. If there would be a platform where function calling conventions differ between C and C++, extern "C" vs extern "C++" matter.

Function pointer indeed cannot have extern "C" applied to it, but a typedef can, and I remember that this is a semi-common method to ensure that function pointer comes from the C land.