Re: Minimum gcc and clang supported to generate FreeBSD binaries

On Jun 20, 2024, at 12:00 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
> On Thu, Jun 20, 2024, 11:43 AM Bakul Shah <bakul@iitbombay.org <mailto:bakul@iitbombay.org>> wrote:
>> On Jun 19, 2024, at 11:49 PM, Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>> > 
>> > Yea. We shouldn't. But it's kinda necessary to have the compilers tested all the time to spot regressions. This stuff is fiddly enough with 2 main compiles and 2 that kinda emulate these two...  comes a point that you need to say enough unless somebody is really, actively using it, our kinda support becomes the worst of both worlds: a random drag on development that isn't actually useful to anybody.
>> 
>> You should'n't have to test with every compiler if the libraries and headers are standard compliant (by default).
> 
> 
> Except things don't work that way. They are standard compliant (which standard do you want?). The standard is the BSD API. In that API, we have two versions of qsort_r: The old, pre-standard and the new standardized version (at least for the moment). You can say you want a different standard, (see _POSIX_C_SOURCE or _XOPEN_SOURCE), but that's on you.

I only meant standard compliant in the sense that a compiler that conforms to C/C++ language standard in existence for 10 year or so old should accept it. 

Who even depends on the old qsort_r? Why can't the fix be in a qsort specific area bracketed by some backward compatibility flag? Anyway I will drop this until (& if) I can come up with a cleaner solution.

Thanks for your patience!