On Fri, Oct 9, 2015 at 4:22 PM, Luca Bruno <lu...@debian.org> wrote: > Hi all, > While testing a recent libuv package, I suddenly realized that when building > via autotools, all assert() sparkled in libuv source are effectively armed. > This differs from building via GYP, which offers a "Release" target where > NDEBUG is defined. Some other portions of libuv also check on NDEBUG > presence/absence. > > Some well-known daemons (eg, BIND and OpenLDAP) have been recently plagued by > a series of DoS, due to armed asserts reachable by specifically crafted input. > > At a first glance, some of libuv asserts may be triggerable with some > malicious input (eg. a NULL path in most of uv_fs_*()), causing the main > application to abort. > > As such, as a packager I have now the following comments: > * should NDEBUG be defined also when building via autotools? > * perhaps it would be better to review the usage of asserts and replace most > of them with error signaling to app. > > Cheers, Luca
This has been discussed in the past and the conclusion was that we're pretty happy with the way asserts are used inside libuv. Their fail-early nature catch a lot of bugs in node.js and other libuv users (and sometimes in libuv itself as well) so I'd recommend against disabling them in release builds. The rule of thumb we follow is that when something is: 1. A run-time error (e.g. out of memory), it should return an error code. 2. A logic error (e.g. passing NULL where that isn't allowed), it should assert. Speaking from prior experience, returning error codes for logic errors just results in harder to debug bugs. There is a strong correlation between a programmer letting slip through invalid values and not zealously checking return codes, to say nothing of how failure code paths are almost always poorly tested. The way we use asserts forces programmers to check their inputs upfront. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
