On Sun, 11 Nov 2018 17:50:10 -0500 Mark Anderson <[email protected]> wrote: > First thing I would do is file a radar. I know that's a terrible > solution, but it'll be the thing anyone at apple will tell us to do > first thing.
I may be mistaken about the problem (see my response to Ken a few moments ago.) This is what I get for trying to think things through while I have a bad headache. Perry > —Mark > _______________________ > Mark E. Anderson <[email protected]> > > > On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger > <[email protected]> wrote: > > > As some of you are aware, XCode 10 no longer searches SDK include > > directories for C headers specified with " marks, as in > > > > #include "stdio.h" > > > > I happened to be reading the C standard (don't ask why) and I've > > discovered this new behavior is wrong and the original behavior > > was correct. To wit, in C11, 6.10.2 Source file inclusion, > > paragraph 3: > > > > A preprocessing directive of the form > > # include "q-char-sequence" new-line > > causes the replacement of that directive by the entire > > contents of the source file identified by the specified sequence > > between the " delimiters. The named source file is searched for > > in an implementation-defined manner. If this search is not > > supported, or if the search fails, the directive is reprocessed > > as if it read # include <h-char-sequence> new-line > > with the identical contained sequence (including > characters, > > if any) from the original directive. > > > > In other words, if you say "stdio.h", and that file isn't found > > in the search path for "-quoted include file names, the compiler > > is to search as though it had been written with a <name.h> > > include. > > > > I know some of our group are Apple employees. Does anyone know > > how to get in touch with the Xcode team to inform them that this > > change of behavior is apparently nonstandard, and breaks the > > expectations of standards conforming C code? > > > > Perry > > -- > > Perry E. Metzger [email protected] > > -- Perry E. Metzger [email protected]
