On Sat, Sep 28, 2013 at 1:44 PM, Christopher Sean Morrison <[email protected]> wrote: ... > (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.
Thanks for clearing up a few things, Sean. After a few days struggling with using -std=c89, it seems to me we would save a LOT of effort by starting with -std=C99. Many of the problems with strict C89 are undeclared functions which are okay with C99. Otherwise one would have to create a lot of bu_* replacements. See ./src/compat/README.compat for a list of such I've found so far. Obviously I've been heading in the wrong direction implementation-wise, but at least I think there is enough info collected so far to say that (1) we need to decide which of the many standards we are truly seeking to meet and (2) using that as the baseline instead of C89. My two cents. Best, -Tom ------------------------------------------------------------------------------ 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
