[clug] C programming question: What goes in 'include' files??

steve jenkin sjenkin at canb.auug.org.au
Tue Aug 23 08:46:26 MDT 2011

The C code I've been looking at recently (hence desire for PPC & 386
builds) has what appears to me some quirky traits:

 - include files contain functions, not just their prototypes
   [as well as the usual constant #defs]

This wouldn't be A Bad Thing, but a library is built with two objects
built using the same include, hence there are multiply defined functions
(one from each include)...

Which could pose the linker a problem...
So I guess to handle that, the 'mk' (not make) files specify LDFLAGS of
" -multiply_defined suppress".

Which I guess is an attempt to ignore the problem.

The 386 environment uses gcc-4.2, which seems to work & produces a
runnable executable.
The LD manpage says the option is obsolete in gcc-4.2, but it runs
without compliant...

The PPC environment uses gcc-4.0, which fails on that link step with an
error (because the suppress only ignores multi-defs on dynamic libs, not

==> Question:
 Is the practice of putting executable code (not hidden with #ifdefs) in
include files, usual or normal???

Is it considered 'good practice' in some C-style?

==> If so, could you point me there?!
    I'd like to understand how these guys think.

steve jenkin


$ grep fpuctl.h */*.c */*/*.c # that's a cheat, but enough for here

emu/MacOSX/os.c:#include <fpuctl.h>
libmath/FPcontrol-MacOSX.c:#include "fpuctl.h"



        ppc_fp_scr_t fpscr = get_fp_scr();
        return ((ulong *)&fpscr)[1];

setfsr(ulong fsr)
        ppc_fp_scr_t fpscr;
        // fpscr = get_fp_scr();
        (((ulong *)&fpscr)[1]) = fsr;

... snip the rest ...


Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA

sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin

More information about the linux mailing list