[Chicken-hackers] [PATCH] Fix result size calculation for enums, resulting in crash (maybe related to #1377?)

[Peter Bex]

Hi all,

I decided to investigate #1377, and while I wasn't able to reproduce it
yet, on 32 bits GNU Hurd I got a segfault due to there being no result
size calculation for "enum" foreign types.  I discovered that if the type
is unknown, the result size is assumed to be zero, so the generate C stub
function receives C_SCHEME_UNDEFINED as a "buffer" (see core.scm:1815).

This is obviously not big enough to hold a bignum that might be returned
from an enum on 32-bit systems, thus we're scribbling into unmapped
memory.

This *might* be the fix for #1377, but I don't think it is, since it
should print "Good, unrepresentable C strings cause errors", before
testing all the FFI conversions.  Nevertheless, the attached patch is
pretty crucial I think.

The patch converts the assumption of 0 size for unknown foreign types
in estimate-foreign-result-size to an error, much like the code in
estimate-foreign-result-location-size already did.  I don't know why
they weren't the same, so beware that this patch may break things.

And finally, this patch also converts the foreign type "(enum x)" into
an "integer" scrutiny type.  Before it would just use "number", but
we know it must be an integer rather than, say, a ratnum, cplxnum or
flonum, so let's use that knowledge.

Cheers,
Peter

0001-Add-foreign-result-size-computation-for-enums-and-en.patch
Description: Text Data

signature.asc
Description: PGP signature