Re: Fix for objc/45925

["Nicola Pero" <nicola dot pero at meta-innovation dot com>]

>> This patch fixes PR objc/45925.  A missing cast in the new fast  
>> enumeration code.
>
> should we also have a diagnostic for the (presumed) user error?
> [that could be a TODO - not to delay solving the ICE].

Having look into this to produce the bugfix, I'm no longer sure it is a user error. :-)

I'd say it was a bug in the new fast enumeration code - a missing cast. ;-)

We probably don't even want to change the testcases.

It would be a user error if the method signature was declared to be something 
completely different (eg, returning an object) and while it would be good 
to double-check for that (and we could add a new bugzilla issue about it), it is 
not terribly relevant to actual real-world usage. ;-)

The most likely problem is that the integer types are declared differently 
by the user.  And, the Apple API seems to specify that 'unsigned int' 
is used as return type in 32-bit, and 'long unsigned int' is used in 
64-bit; and the same for the 'len' parameter.  So, in a sense, they already do
it and most likely GNUstep will do the same as it's implementating the same API ;-)

But (once we fix objc/45924 and add the missing cast) there is nothing 
to change there in the compiler to support that (other than our documentation).

You can use different integer types in your method declaration/implementation, 
and it should still work.

The 'len' argument always receives the constant integer value 16 as parameter, 
which should fit into any integer type, no matter what integer type you declare.

The return value will be whatever type you declare, and is then cast to 
a 'long unsigned int' which hopefully is big enough (also considering that at runtime
the return value will always be a number between 0 and 16 since it has to be smaller
than 'len' according to the specification).

Tonight I'll submit a patch that updates the documentation to clarify this issue. :-)

Thanks

PS: Let me know if I missed something