Re: Likely a good frog project for someone with C knowledge

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Tue, Aug 16, 2011 at 3:38 PM, David Kastrup <address@hidden> 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