[Patch, Fortran, OOP] PR 46971: [4.6 Regression] ICE on long class names

Janus Weil janus@gcc.gnu.org
Fri Dec 31 11:15:00 GMT 2010


>>>> A stronger argument would be the lack of uniqueness, i.e. a hashed
>>>> name colliding with a plain-text name, but I think this is practically
>>>> impossible.
>>>
>>> I think we have had that discussion before, sort of :-)
>>
>> at least a similar one ...
>>
>>
>>> Could you maybe insert a couple of leading underscores into the hashed
>>> class name so that a user would have to do something really illegal
>>> (i.e. make up a class name with two leading underscores) to get a
>>> collision?
>>
>> I think it's easier to do the opposite: Make sure the plain-text
>> string contains a character which cannot appear in the hash string
>> (which is in hex: 0-9, A-F). Let's take the underscore (a single one
>> is sufficient), since we already have that in most cases. I have
>> modified the patch to make sure that it appears in *all* cases (cf.
>> get_unique_type_string). There you go, the improbable is now
>> impossible ;)
>>
>> Another small change I made in 'gfc_hash_value' is to remove the
>> modulus. It only saved two digits in the mod file, but it increased
>> the probability of a hash collision.
>>
>> Ok for trunk? (I'll do another regtest just to be on the safe side.)
>
> Yes, OK.  and yes I have been following the thread and did review the patch
> and since i am in a later time zone, thought I would jump in here.

Thanks, Jerry. Committed as r168363. (Btw, without removing the
modulus, which of course was there for a reason, namely that the
module reading of integers is limited to positive integers up to
10**8, cf. parse_integer in module.c. I guess one could think about
loosening that restriction, and/or writing the hash to the module file
in hex code ...)

Thanks for the comments, everyone!

Cheers,
Janus



More information about the Gcc-patches mailing list