Hi, with -I- now being deprecated, how is -iquote going to replace its functionality? I have the following test case with ./$ cat a.c #include "a.h" ./$ cat a.h #error dont include me ./$ cat a/a.h int foo( int bar ); Now in the 'good-old-days' I could compile that code via: ./$ gcc -c -I- -Ia a.c because -I- cleared the list of include directories for "" searches, most importantly: including '.' These days I try: ./$ gcc-4.0.0 -c -I- -Ia a.c cc1: note: obsolete option -I- used, please use -iquote instead so I go ./$ gcc-4.0.0 -c -iquote -Ia a.c In file included from a.c:1: a.h:1:2: error: #error dont include me That didn't work... What about: ./$ gcc-4.0.0 -c -iquote '' -Ia a.c cc1: error: a.c: not a directory ... and now gcc reads from stdin, typing ^D brings it back ... other alternatives: ./$ gcc-4.0.0 -c -iquote a -Ia a.c In file included from a.c:1: a.h:1:2: error: #error dont include me or ./$ gcc-4.0.0 -c -iquotedir a -Ia a.c In file included from a.c:1: a.h:1:2: error: #error dont include me It sure seems that -iquote does not strip . from the "" search path. -------------------------------------------------- This isn't purely academic - I know that I can change the #include "a.h" to and #include <a.h> to avoid this specific problem but I have to deal with vendor supplied header files that use the "" notation unfortunately. Did the deprecation of -I- in favour of -iquote omit the complete original behaviour or is this a plot to force coders to stick to the C standards? ;-) Wolfgang