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
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.
More information about the FFI