On Sun, Jun 17, 2012 at 12:36 PM, Matt Rice <[email protected]> wrote:
> the whole nested function thing, just reeks as a workaround for
> keeping the number of allocator functions/function pointer types from
> exploding.
I actually do not think that is the situation here. The larger usage
pattern is that we are calling the FileSystem::open() routine in order to
obtain a file object. The concrete file object is an opaque subtype of a
known (generic) supertype. The intent of the code is to stack-allocate the
file object. What happens in the C code is something approximately like
this:
File *theFile = alloca(FileSystem::ConcreteFileSize);
result = FileSystem::open("fileName", theFile,
FileSystem::ConcreteFileSize);
the call to FileSystem::open populates the structure. This is the *only*
allocator function that the library provides.
If the object were not being stack-allocated, then we could simply have
FileSystem::open return a newly allocated File object, and all would be
well. If the requirement to stack allocated is removed, then a whole bunch
of aspects of that code become a good bit simpler. To give one example, the
API must currently say what happens to the "object" when FileSystem::open()
fails. Even if the call fails, the File object being returned must be
well-formed.
What has me a bit provoked about this pattern is a couple of things:
1. The pattern is well motivated, but I haven't seen it discussed anywhere
in a safe language context.
2. If we want to compile C code in a safe way, we need to deal with this,
which raises the question: how?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
