Seeming flaw in Xcode 10

[Mark Anderson]

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.

—Mark
_______________________
Mark E. Anderson <emer at emer.net>


On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger <perry at piermont.com> 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                perry at piermont.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181111/7b4867cd/attachment.html>