Han-Wen Nienhuys <hanw...@gmail.com> writes:
> On Tue, Aug 16, 2011 at 3:38 PM, David Kastrup <d...@gnu.org> wrote:
>>
>> Compile Lilypond with
>> -DSCM_DEBUG_TYPING_STRICTNESS=2
>>
>> The guile documentation states quite clearly
>>
>> -- C Type: SCM
>> `SCM' is the user level abstract C type that is used to represent
>> all of Guile's Scheme objects, no matter what the Scheme object
>> type is. No C operation except assignment is guaranteed to work
>> with variables of type `SCM', so you should only use macros and
>> functions to work with `SCM' values. Values are converted between
>> C data types and the `SCM' type with utility functions and macros.
>>
>> Now the Lilypond code base is chock full of code comparing SCM values.
>> And it likely also contains a number of cases where C types (like
>> booleans) and Scheme type are getting mixed up.
>
> The abstraction that guile uses is not that tight. I would start
> worrying about this once the GUILE team starts actually using the
> constraints mentioned in the above snippet. Given the current release
> rate of Guile, I wouldn't be too worried.
>
>> But with the current code base, cleaning this all up is going to be a
>> lot of work. Not hard to do, but a lot.
>
> The only real problem are boolean conversions because they are very
> wrong, ie,
>
> SCM x = ...
> if (x) {
> ..
> }
>
> for the rest, making lilypond SCM typing clean is just a lot of work
> with no benefits at all.
I have also seen comparisons of Scheme numbers with ==:
if (scm_from_int (d) == numbers_[i]->get_property ("direction"))
(multi-measure-rest-engraver.cc)
which is strictly not defined to work (you can't compare numbers
reliably with eq? unless they are identical rather than merely the
same).
> (and I am speaking as a GUILE developer here as well)
So what does relying on undefined behavior buy us apart from the
inability to debug type errors?
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
