Re: Minimum gcc and clang supported to generate FreeBSD binaries

Bakul Shah <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <[email protected]>
On Jun 20, 2024, at 12:00 PM, Warner Losh <[email protected]> wrote:
> 
> On Thu, Jun 20, 2024, 11:43 AM Bakul Shah <[email protected] <mailto:[email protected]>> wrote:
>> On Jun 19, 2024, at 11:49 PM, Warner Losh <[email protected] <mailto:[email protected]>> 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!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.