Re: [MiNT] C99 stuff in public GEMlib headers?

["Roger Burrows" <rfburrows@ymail.com>]

On 17 Nov 2012 at 11:37, Arnaud BERCEGEAY wrote:
> 
> 2012/11/16 Eero Tamminen <oak@helsinkinet.fi>
> 
> > >
> > > The file compiler.h is here for compatibilty issues of the compiler (it
> > > does the job for gcc, old version of gcc, pure C, sozobonx C, and maybe
> > > lattice C too...)
> >
> > If you mean that compiler.h e.g. defines "inline" as empty for compilers
> > that don't support "inline" keyword (which is C99 feature), this would
> > mean that instead of static inline, you will have the static function
> > in *every* C-file that includes gem.h.
> >
> >
> But but these are "static" functions to a C file, i mean it's private for
> each C file, and so, the compiler may ignore these 'unused piece of code'
> when compiling.
> BTW, these are very short function, only a wrapper to the mt_aes
> corresponding function.
> 
PureC ignores static functions which are never referenced, i.e. does not 
generate code for them.  LatticeC does not alas, so there is huge code bloat 
when trying to use LatticeC with code that has many small modules (e.g. 
Windom).  And I don't know if there's anything in the C standard that says that 
a compiler *must* ignore static functions that are never referenced (although I 
would agree that it's logical behaviour).

There is no easy way around this, so if you use "static inline" you're 
effectively preventing the use of LatticeC (which may not be of concern to 
anyone except me ;-)).  I don't know how it affects other compilers apart from 
PureC.

Roger Burrows