Re: Seeming flaw in Xcode 10

[Ken Cunningham]

> On Nov 11, 2018, at 3:07 PM, Perry E. Metzger  wrote:
> 

> No, that works if  is in the system includes path, and
> that's standards conformant.



What I know about this, no doubt incomplete,  comes from here:

https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes/build_system_release_notes_for_xcode_10
The legacy header map that was generated when the Always Search User Paths 
(ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by the new build 
system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and migrate to using modern 
header include syntax. Add any needed header files that are in the project 
repository to the Xcode project to ensure they are available for use in 
#include (via the project wide header map). Use quote-style include 
("example.h") for project headers, and reserve angle-bracket include 
() for system headers.

Re: Seeming flaw in Xcode 10

[Helmut K. C. Tessarek]

On 2018-11-11 17:36, Perry E. Metzger wrote:
> 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?

I don't want to be the devil's advocat, but reporting bugs to Apple is
pretty much the same as sending them to /dev/null.

I've tried several times to report bugs in the API, app frameworks,
Xcode, and even macOS. Nothing happened, not even a reply, and I gave up.

But, if you are able to do so (with either a confirmation or even a fix
by Apple), please let me know how you did it.

Cheers,
 K. C.

-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature

Re: Seeming flaw in Xcode 10

[Perry E. Metzger]

On Sun, 11 Nov 2018 17:50:10 -0500 Mark Anderson 
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 
> 
> 
> On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger
>  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  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 
> > 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. Metzgerpe...@piermont.com
> >  



-- 
Perry E. Metzgerpe...@piermont.com

Re: Seeming flaw in Xcode 10

[Perry E. Metzger]

On Sun, 11 Nov 2018 15:00:53 -0800 Ken Cunningham
 wrote:
> > 
> > On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger
> > mailto:pe...@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 
> 
> And vice-versa — it will no longer search the source path for any
> files specified with angled brackets either.
> 
> #include 
> 
> just fails.

No, that works if  is in the system includes path, and
that's standards conformant.

Actually, looking at this, I wonder if I'm on crack and the problem
only exists in that direction and I'm utterly mistaken. I've had a
migraine for some hours and may not be thinking straight. Checks to
follow...

Perry

-- 
Perry E. Metzgerpmetz...@macports.org

Re: Seeming flaw in Xcode 10

[Ken Cunningham]

> 
> On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger  > wrote:
> As some of you are aware, XCode 10 no longer searches SDK include
> directories for C headers specified with " marks, as in
> 

And vice-versa — it will no longer search the source path for any files 
specified with angled brackets either.

#include 

just fails.


I can see the logic. Uncertainty makes the source of the header file less 
certain, causes errors if people happen to name headers with poorly-chosen 
names, so this reduces bugs.

the release notes were pretty clear that this was completely on purpose.

I’m sure there were many meetings in boardrooms where this was already settled.

Ken

Re: Seeming flaw in Xcode 10

[Mark Anderson]

I can file one against the betas as well.

—Mark
___
Mark E. Anderson 


On Sun, Nov 11, 2018 at 5:50 PM Mark Anderson  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.
>
> —Mark
> ___
> Mark E. Anderson 
>
>
> On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger 
> 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  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  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. Metzgerpe...@piermont.com
>>
>

Re: 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 


On Sun, Nov 11, 2018 at 5:36 PM Perry E. Metzger  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  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  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. Metzgerpe...@piermont.com
>