> On Aug 4, 2015, at 8:18 AM, Hans Petter Selasky <h...@selasky.org> wrote: > > Wouldn't the argument be the same for queue.3 . Once C-compilers finally > decide to compile time support queues, we should throw queue.3 aswell?
Sure! Not right away, and not in a way that causes unnecessary churn, but if there are benefits (e.g., better optimizations, better standards compliance) and a diversity of compilers support a new C feature in both our stable branches and the ports tree (for lots of architectures), then why not? (note: by “diversity”, I don’t mean “Clang and GCC support it on amd64 but none of the vendor toolchains for other important architectures do”) There are lots of things like this, where FreeBSD folk historically said, “K&R/C89/C99/C11 doesn’t provide feature X, so we need to write some macros to do it ourselves.” That’s great, FreeBSD was ahead of its time, but once the C standard catches up, isn’t it good to hew to the standard wherever it’s practical to do so? stdatomic.h, _Generic, _Noreturn, static assertions... the language is growing lots of useful features. Wouldn’t it be good to adopt them when we can and trim non-standard code? Cheers, Jon -- jonat...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
