On Sep 25, 2013, at 4:18 PM, Tom Browder wrote: > A really basic (perhaps stupid) question: is the goal of the strict > C89 (POSIX) checking to (1) get an error-free build or (2) to also > get a complete and successful test of the error-free build?
(1) and (2) ... and (3). (3) is ensuring we're not relying on extension behavior. We do this by (A) disabling features where not critical (e.g., HAVE_CARBON_CARBON_H in src/libdm/focus.c), by (B) forcing an extension feature where we know it's almost always been available (rare) but the benefit is substantial (e.g., inlining), or, most often, by (C) creating our own interface (e.g., bu_sscanf() so we can use %z) so we have a proper fallback implementation. The goal is to have a reasonably complete compilation that does not rely on extension behavior and can be claimed as being compliant with the standard. It sets a baseline for future compatibility work and usually makes porting easier. In general, this means avoiding any compiler macros that start with an underscore as that is basically the entire difference between -std=c89 and -std=gnu89 (it basically just sets _USE_GNU, _BSD_SOURCE, _GNU_SOURCE, and a few others). We're not just trying to avoid -std=gnu89 while still defining preprocessor symbols that enable those extensions. It's considering the ABC's above and usually deciding whether to conditionally turn the feature off or determine whether we need a wrapper/implementation/alternative. Cheers! Sean ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
