> I'm looking at (besides input on what I've got currently):
So far I see it fine... except:
            int len = TREE_STRING_LENGTH (strl);
should be:
            int len = TREE_STRING_LENGTH (strl) - 1;
since the draft says "its length excluding the terminating null character".

Also, I had to change:
            identifier = perform_koenig_lookup (identifier, vec,
                                                /*include_std=*/false);
into:
            identifier = lookup_function_nonclass (identifier, vec,
/*block_p*/0);
to make it work. The issue here is that "perform_koenig_lookup" does
not work with built-in types, since they don't have associated
namespaces, I guess. Not sure about the block_p parameter, however.

> 1. A warning or error if a user chooses a suffix that gcc uses.  I was
> surprised that 'w', 'q', 'i', 'j' and several others were used by gcc for
> floats.  I won't be the only one.  The standard is clear that
> implementations get first crack at these but it shouldn't be a mystery or a
> surprise when things don't work as expected.
Agreed.

> 2. Should we at least pedwarn about user not starting a suffix with an
> underscore?  Probably.  Non-underscore suffixen are reserved to the
> implementation but I think a user should be able to use one if it's not used
> by gcc though the user risks non-portability and potential but unlikely
> future breakage.
Hmmm, I don't think so. Reserved but unused identifiers are not warned
about anywhere, AFAIK.
For example, I type:
   int __x, _Y;
and no warning at all.
Sure it would be pedanticly nice to have such a warning, but it would
be another topic.

> 3. The big one: Getting the integer(long long) and float(long double)
> suffixes that are not used by gcc out of the preprocessor.  Then we can
> build the calls.
Oh, I see the problem...

> 4.  If, for long long and long double the usual signature is not found,
> first look for a: _suffix(char*) and failing that: template<char...>
> _suffix().  So we'll need to make the lookup of these two signatures more
> complex.
Yes, the problem here is that we don't have to use the usual overload
resolution, but check the results of the lookup by hand.
I guess that it won't be so easy...

Regards.
Rodrigo

Reply via email to