Re: Minimum gcc and clang supported to generate FreeBSD binaries
- In reply to: Warner Losh : "Re: Minimum gcc and clang supported to generate FreeBSD binaries"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 20 Jun 2024 20:30:03 UTC
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!