From: ludovic.courtes@laas.fr (Ludovic Courtès)
To: Kevin Ryde <user42@zip.com.au>
Cc: guile-devel@gnu.org
Subject: Re: struct tail array, compare and segv
Date: Tue, 13 Feb 2007 09:35:55 +0100 [thread overview]
Message-ID: <87fy9atpxw.fsf@laas.fr> (raw)
In-Reply-To: <87ejovt8w9.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 13 Feb 2007 07:31:50 +1100")
Hi,
Kevin Ryde <user42@zip.com.au> 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.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2007-02-13 8:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <JBZ0GM$CFED99A75273895A8023C7E1DE3B0AD2@poste.it>
[not found] ` <877ivlz0ua.fsf@zip.com.au>
[not found] ` <87sle8ebld.fsf@laas.fr>
2007-02-12 20:31 ` struct tail array, compare and segv Kevin Ryde
2007-02-13 8:35 ` Ludovic Courtès [this message]
2007-02-25 23:47 ` Kevin Ryde
2007-02-26 9:22 ` Ludovic Courtès
2007-02-26 20:01 ` Neil Jerram
2007-02-27 0:50 ` Kevin Ryde
2007-02-28 21:45 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fy9atpxw.fsf@laas.fr \
--to=ludovic.courtes@laas.fr \
--cc=guile-devel@gnu.org \
--cc=user42@zip.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).