[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).
Correct.
>
> 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! :-)
felix