This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Framework support for darwin


Mike Stump wrote:-

> No, actually I had a grep failure of 'sizeof (cpp_dir' and I wanted it 
> to hit.  Your latest code prefers cpp_dir over struct cpp_dir, so I 
> changed it to be consistent with _your_ code in cppfiles.c.  I'm happy 
> to change all instances to be one form or the other form, just let me 
> know which form you want.  In the below patch I copy the style of 
> cppfiles.c by removing the struct in the above line.

Hmm, so it's inconsistent before, and after?

> Sure.  file is expected to have err_no set by this routine, or one 
> below it by the caller.  Since open_file is static and has access to 
> the _cpp_file data structure, it can so modify things.  In the case 
> that construct doesn't construct a pathname, we want to get out of 
> normal processing, but, we cannot call open_file to set things up, as 
> it is static, and we don't want to export _cpp_file, so, either we do 
> it here like this, or we export _cpp_file, or export and accessor that 
> will set err_no.  I think having the code inline to handle this is 
> safer than an accessor, and I didn't want to export _cpp_file, or 
> open_file.

OK.  Perhaps these functions should return an errno.  I'll look into
that after your patch.

> >I don't think a return value is needed, also note I don't "return;".
> >Doing that is not optimal as the found file is not then entered in
> >the hash table.
> 
> Ah, but we don't want the file entered into the hash table.  Since the 
> lookup is context dependent, an entry in a hash table would defeat the 
> next context dependent lookup, making it context independent, which, is 
> wrong.

Yuk!  This is nasty.  Including the same thing and getting something
different is ... counterintuitive.

> >Please put this above ino and dev - they're tacked on the end as a
> >front-end kludge; the rest is really cpp-internal.  Also, can it
> >return "const char *"?
> 
> Sure, if you prefer cast that cast away const in cppfiles.c, or if you 
> want me to do up lots of changes to add const to all the code.  Let me 
> know how invasive you want the changes to be.  Complete job?  Cast away 
> const one ply away?  Leave it alone?  Other?

file->path is const already.  If a cast is needed, put it in cppfiles.c.

> I've included all the changelog entries in this, as I think we have 
> most of the code where it is going to live in this version.

Thanks,

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]