[Top][All Lists]

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

Re: [Chicken-hackers] [PATCH(5)] Add allocation size helpers C_SIZEOF_ST

From: Felix Winkelmann
Subject: Re: [Chicken-hackers] [PATCH(5)] Add allocation size helpers C_SIZEOF_STRUCT and C_SIZEOF_CLOSURE
Date: Sat, 13 Sep 2014 23:30:20 +0200 (CEST)

> While working on the "numbers" egg, I noticed we don't have a size
> calculation macro for record types and closures.  Attached is a patch
> to add these.  Please note that the size calculation of the closure
> in C_call_with_cthulhu was wrong, as well as the allocation in
> handle_interrupt (including misleading comment), unless I completely
> misunderstand what it's doing.

Ok. The former really allocates a slot too much, but that makes no
difference besides wasting a word in the nursery. The latter used to
intern "##sys#interrupt-hook" on the fly once, IIRC. So the comment is
indeed wrong.

> I am a little unsure what the correct "length" argument for closures and
> structures should be: naturally one would assume it's the number of slots.
> However, the C_closure() function accepts a "number of cells", which
> includes the cell for the function pointer, and C_structure() accepts
> the number of cells, which includes the "slot" for the struct type tag.
> This is a little confusing, as you would expect these to accept the
> number of user slots, excluding structure type tag or function pointer
> (so, if a record type has no slots, it's 0 and not 1 like it is now).

Using the full number of block-items/cells/slots seems less confusing
to me than using implicit slots, but perhaps that's just me.

> I tried to change this, but I ended up in a quagmire: there's a
> specialization rewrite which assumes that the number of arguments to,
> say, C_a_i_record2 is 2.  Anyway, it would be too much of a breaking
> change (bootstrapping issues and whatnot).


> So in the end I decided that it's probably the simplest to just keep
> things the way they are, and use the "low level" slot size as the
> interface everywhere.  I've added this to the "C interface" document.

Very good, thanks for doing this.

> More confusing things: It's called STRUCT(URE) everywhere, but the
> constructors are called C_a_i_record[N].  The C_closure() function
> accepts the slot count, including the function pointer but it has
> the function pointer as a separate argument. 

It's the first argument. What qualifies it as "separate"?

> The C_record()/C_structure
> only accept a count and have the tag as part of the rest arg.  The
> C_make_structure() function, however, has the type as an explicit
> argument with only the slots as varargs.

Are you complaining about the C function prototypes, then?
> Not sure if we should fix these now, but they sure are confusing.

Nah... it's all wonderfully consistent! :-)


reply via email to

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