> With Java the middle end should never see an uninitialized variable.
> Uninitialized variables are precluded by the language definition, or
> the bytecode verifier.
Then if there's no other way in the language to create an undefined value,
Java should certainly use the "undefined" choice, like C
> "Richard" == Richard Kenner <[EMAIL PROTECTED]> writes:
Richard> The simplest example of that is an uninitialized variable.
Richard> I think the best approach is to use flags set by the front
Richard> end to indicate which of these is to be the case. For C, I
Richard> believe (1) is always
> So, the most obvious answer to these points is that arithmetic is
> always performed in a type where TYPE_MIN/MAX_VALUE is
> naturally defined and so we can rely on two's complement arithmetic.
Right. In the Ada case, that's required by the language anyway.
> The question that is retained is,
On 6/7/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
[Moved to gcc list from gcc-patches].
> > So now objects can have values outside of their type?
>
> If we accept that it is correct that TYPE_PRECISION is not synonymous
> with TYPE_MIN_VALUE and TYPE_MAX_VALUE, then, yes, objects can have
> v
[Moved to gcc list from gcc-patches].
> > So now objects can have values outside of their type?
>
> If we accept that it is correct that TYPE_PRECISION is not synonymous
> with TYPE_MIN_VALUE and TYPE_MAX_VALUE, then, yes, objects can have
> values outside of their type (isn't that the whole poin
