Re: [Chicken-hackers] Pessimizing undefined behavior

[felix . winkelmann]

> >> Based on my limited observations (##core#undefined) will always have
> >> the value 30L at runtime. This is not equal to 6L (or #f). Therefore
> >> an undefined value in conditional test will always cause the true
> >> branch to be chosen.
> >
> > That's an implementation artefact, (begin) may also return #f, which would
> > be legal according to the standard. "Undefined" is not a value nor a type.
>
> You mean the compiler currently sometimes returns #f for (begin)?

No, but it could, depending on some arcane optimization that someone
may implement in the future (or not). It's simply open to the implementation.

> > My basic point is that "undefined" is nothing that should have any strict
> > interpretation, even though it may evaluate to some constant X. That's
> > why it has been considered "undefined" in the first place.
>
> Yeah, R5RS only says expression having unspecified value has to return
> some object without an error. It's up to the implementation what object
> that should be.
>
> And, as I took a look at the spec, I saw that we've been talking about
> _unspecified_, not _undefined_ (used in 7.2).

I don't think it makes much of a difference in this context.

If you think this is important, then of course add a
treat-warnings-as-errors switch may be a compromise. I personally don't find 
this
very useful - in collaboratively developed C projects it can
lead to a lot of pain. It's also the case that we already have too many
compiler options anyway.


felix