Re: Merge cpplib and front end hashtables, part 1

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Zack Weinberg wrote:-

> I put a brain dump on charset handling into the cpplib projects web
> page.  It remains a pretty good statement of what I think our end goal
> should be in terms of user-visible behavior.  It'd be reasonable to do
> a subset of this stuff to begin with, then get better as things go on.

I don't understand how the user is going to communicate the encoding
of a file to us.  My understanding is charset encoding is on a
per-file basis; i.e. there is only one encoding per file.

But since some header files are system header files, clearly the whole
translation unit cannot be in a single charset.

So we need a way to specify it on a per-file basis, presumably in the
file itself.  But how can we grok what's in the file if we don't know
what charset it's written in?  It seems like chicken-and-egg to me.

> *nod* Although, do watch out for L"" and @"".  If I remember
> correctly, they're contagious - "foo" L"bar" "baz" is valid and
> equivalent to L"foobarbaz"...

Yes, that's my understanding.  I've read the Apple ObjC manual over
the last 2 days, quite interesting :-), but I couldn't find any
mention of ObjC strings.

> Didn't Nathan Sidwell fix that already?

I don't know.

> Have you been following the header-names discussion on comp.std.c? We
> may need more than that :(

Yeah, I saw it.  I don't think

#include <stdio.h

is worth worrying about, to be honest.  But I don't see what that has
to do with this - directives are transparent to CPP clients, and the
next token they see will either be a string literal to be merged, or
not a string literal and you're done.

> I meant, variable sized in that each front end's struct
> lang_identifier is different, and middle-end code has to have hacks to
> cope.  See set_identifier_size etc.

set_identifier_size and similar kludges are going away soon if I have
anything to do with it :-)

Neil.