guile-devel
[Top][All Lists]
Advanced

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

Re: struct tail array, compare and segv


From: Ludovic Courtès
Subject: Re: struct tail array, compare and segv
Date: Tue, 13 Feb 2007 09:35:55 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Hi,

Kevin Ryde <address@hidden> writes:

>> but their semantics are a
>> little fuzzy to me.  In particular, I don't understand why the size of
>> the tail array can be specified in both `make-vtable-vtable' and
>> `make-struct': What does that mean?
>
> Nosing around the code, I think make-vtable-vtable adds space to the
> vtable (or rather vtable-vtable) struct like "class data".  Then
> make-struct adds space to a struct created from it like "instance
> data".

Hmm, right.

>> It seems that the code is a bit unclear on this too:
>>
>>   guile> (define v (make-vtable-vtable "pr" 0))
>>   guile> (define s (make-struct v 123))
>>   guile> (struct-ref s 10)
>>   Segmentation fault
>
> Digging around I think that to have a tail array you're meant to say
> "pR" or "pW" or whatever at the end of the layout.  Without R, W or O
> then it looks like the internal func scm_struct_init doesn't
> initialize the tail array contents, so then scm_struct_ref reads out
> garbage as an SCM, and that can cause a segv if you attempt to print
> it.

Yes, ok.

> Should make-struct throw an error, or should it initialize?  I guess
> initializing is the smallest change, but it looks like struct-set!
> refuses to work in the tail part without "W" at the end, so maybe
> R,W,O is how it's meant to be.

Yes, `make-struct' should check the vtable's layout last field, checking
whether it contains a capital letter, and throw an error if
TAIL_ARRAY_SIZE is non-zero and the last layout letter is not
capitalized.  Once this check is added, `struct-ref' can keep blindly
trusting the `n_words' thing.

The layout machinery is a bit heavyweight and ought to be factorized I
think.  Layout info could also be compiled to a more readily usable
form.

Thanks,
Ludovic.




reply via email to

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