Michael Weber <michael.weber@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