Re: stdint.h type information needed

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

FX wrote:
>>  LOL, I forgot to attach mine didn't I?  It's basically the same, I
>> copied
>> and pasted the newlib version and tweaked a couple of the definitions
>> so they
>> were identical to Cygwin's stdint.h.  I suspect we're simply missing some
>> needed definition somewhere, so I won't send mine now you've sent yours.
>>
>>  Neither adding /usr/include/uchar.h, nor defining char{16,32}_t in
>> /usr/include/stdint.h fixed this for me.
> 
> It's simpler than that actually: the node for "unsigned short int" is
> not defined, but that of "short unsigned int" is. So we have to write in
> our target macros the following form: "(short|long|long long) unsigned
> int". I don't understand why, but it appears to work :)

  Ah, because it's initially based on string-matching when it creates the
identifiers to find an existing one that already has the binding info set.  I
don't know what the existing one is that's being matched, but that's a simple
solution, thanks for the tip!

  Side note: isn't it wrong to have multi-word identifiers?  Or at any rate
new, unusual and as-yet undocumented?

9.2.2 Identifiers
-----------------

An `IDENTIFIER_NODE' represents a slightly more general concept that
the standard C or C++ concept of identifier.  In particular, an
`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters.

  If we're going to have them, and word ordering is critical in the identifier
but not in the language semantic it represents, it should probably be
mentioned here.  I don't think spaces come under the category of
"extraordinary characters" because they're not just literals here, they are
semantic separators.


    cheers,
      DaveK