chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Pessimizing undefined behavior


From: megane
Subject: Re: [Chicken-hackers] Pessimizing undefined behavior
Date: Thu, 04 Apr 2019 15:51:25 +0300
User-agent: mu4e 1.0; emacs 25.1.1

address@hidden writes:

>> >> 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.
>

There's the possiblity of documenting this optimization:

"If the expression's value can be determined statically to be undefined
the value will be considered truthy. Otherwise the value can be
anything, including false."

Considering undefined as truthy value have two benefits:

First, even if this optimization you speak of is implemented the user's
code would still stay deterministic for the parts that can be statically
analyzed. So if the undefined is sometimes a #f and that uncovers a bug
it will be easier to debug.

Secondly, this enables the scrutinizer to find more bugs. For example
this code doesn't give any warnings, even with -verbose:

  (+ 1 (if (print 1) 'a 1))

With the patch there would be a note for always true value in
conditional _and_ warning for passing a symbol to +.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]