On Thursday, January 23, 2014 14:54:53 Mark Wielaard wrote:
On Thu, 2014-01-02 at 17:48 -0500, Mike Frysinger wrote:
> the majority of those changes are just for old toolchains (looks like
> gcc-4.3 is the oldest version that'll work, but that's what we've been
> requiring in glibc for a few releases and no one seems to mind, so
> shouldn't be an issue).
>
> i think these belong in the main branch though:
>
> 35ae9cf964c2de52bb4d03412334fe83338393ee
> - adds an abort() after an assert()
> if you build with -DNDEBUG, the assert() is a NOP, and the code can
> continue running when it clearly shouldn't.
More stuff breaks when you build with -DNDEBUG. Are you sure we want to
support that setup? In general we seem to use assert and/or abort a lot
for non-reachable code paths. It would be nice to have a better solution
for that, especially in places where the compiler would be able to check
that assertion. I am not sure what the correct way to express that is
though.
newer glibc/gcc versions have static_assert() which should work even w/NDEBUG.
if there are no plans to support running with asserts turned off, then maybe
add a #error when that is defined ?
> a3462c319770a035e8a1deed5b49f5a0d95c5a2b
> - support systems that lack tls
> probably not terribly important as every arch that is supported by current
> glibc has tls support now, but not every C library supports tls. plus,
> this change has like no overhead for the project (it's a minor tweak to
> configure.ac only).
That is for the unsupported configure option --enable-thread-safety for
which we already warn it should not be used.
then it should be easy to merge as you won't be breaking anything new :). as
for warning, i think the code really only says "hey tests might break".
that's not terribly strong if the project really doesn't want people using it.
maybe change
-mike