Again: FFI syntax

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Fri Jun 1 00:34:06 EDT 2001


Michael Weber <michael.weber at post.rwth-aachen.de> wrote,

> On Wed, May 30, 2001 at 22:59:37 +1000, Manuel M. T. Chakravarty wrote:
> > So, it all boils down to the question of whether this
> > (probably rare) case justifies the (not very large) extra
> > complexity of allowing header file names enclosed in <>.
> > 
> > I am happy either way, but slightly tend to the simpler
> > solution (not allowing <>).  Would everybody who prefers to
> > have <> please say so and briefly say why?
> 
> Sorry for dropping into the discussion, but...

You are always welcome, Michael :-)

> Using "" instead of <> once caused me some problems (can't recall what
> it was in particular).  However, since then my standard was to always
> use <> and handle the "" case by adding -I. parameters...  That would
> also have the benefit of being somewhat less dependant on the
> behaviour of a implementation (as somebody quoted from the standard).
> If you put -I. in front, it will always get searched before include dirs 
> given by subsequent -I options, right?

This is not guaranteed by the standard.  The ISO C99
standard (as quoted by Fergus earlier) says for <>

  [..] searches a sequence of implementation-defined places
  [..] How the places are specified [..] is
  implementation-defined.

However, the standard does guarantees for "" that 

 The named source file is searched  for  in an
 implementation-defined manner.   If [..] the  search
 fails,  the directive is reprocessed as if it read

        # include <h-char-sequence> new-line

So, it seems that using "" is more portable than using <> in
conjunction with -I.

I will leave it with "" as the only option, then.

Cheers,
Manuel




More information about the FFI mailing list