[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Likely a good frog project for someone with C knowledge
From: |
David Kastrup |
Subject: |
Re: Likely a good frog project for someone with C knowledge |
Date: |
Wed, 17 Aug 2011 00:17:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
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
- Re: Likely a good frog project for someone with C knowledge, (continued)
- Re: Likely a good frog project for someone with C knowledge, David Kastrup, 2011/08/16
- Re: Likely a good frog project for someone with C knowledge, Bertrand Bordage, 2011/08/16
- Re: Likely a good frog project for someone with C knowledge, David Kastrup, 2011/08/16
- Re: Likely a good frog project for someone with C knowledge, Bertrand Bordage, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, David Kastrup, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, David Kastrup, 2011/08/17
Re: Likely a good frog project for someone with C knowledge, Han-Wen Nienhuys, 2011/08/16
- Re: Likely a good frog project for someone with C knowledge,
David Kastrup <=
- Re: Likely a good frog project for someone with C knowledge, Han-Wen Nienhuys, 2011/08/16
- Re: Likely a good frog project for someone with C knowledge, Werner LEMBERG, 2011/08/16
- Re: Likely a good frog project for someone with C knowledge, Graham Percival, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, Trevor Daniels, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, Ian Hulin, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, David Kastrup, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, Reinhold Kainhofer, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, David Kastrup, 2011/08/17
- Re: Likely a good frog project for someone with C knowledge, David Kastrup, 2011/08/17
Re: Likely a good frog project for someone with C knowledge, Han-Wen Nienhuys, 2011/08/17