A safer interface for core.stdc
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Sun Feb 8 07:36:41 PST 2015
On 2/8/15 2:54 AM, Johannes Pfau wrote:
> Am Sat, 07 Feb 2015 15:50:53 -0800
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
>> @trusted int setvbuf(T)(FILE* stream, T[] buf, int mode)
>> if (is(T == char) || is(T == byte) || is(T == ubyte))
>> {
>> return setvbuf(stream, cast(char*) buf.ptr, mode, buf.length);
>> }
>>
>
> This can still cause memory corruption if `buf` is GC-allocated. You'd
> have to pin the buffer which might not be easy in such a low-level
> wrapper. OTOH in a higher level wrapper (std.stdio.File) you can simply
> keep a reference to the buffer.
Good point, thanks. Moving GCs didn't occur to me.
>> @trusted int stat(in char[] name, stat_t* p)
>> {
>> if (isZeroTerminated(name)) return stat(name.ptr, p);
>
> How would you implement `isZeroTerminated` in a memory safe way? We have
> exactly the same problem in toStringz and nobody ever came up
> with a really safe solution. The best you could do is using special
> types for zero-terminated strings but that might be cumbersome to use.
I thought of a few things, nothing is 100% foolproof. But I'm not too
worried - many of these functions issue system calls, and the cost of a
malloc/free pulse is unlikely to be measurable. With opportunistic use
of alloca it gets even better.
>> auto t = cast(char*) malloc(name.length + 1);
>> scope(exit) free(t);
>> memcpy(t, name.ptr, name.length);
>> t[name.length] = 0;
>> return stat(t, p);
>> }
>>
>> Such wrappers would allow safe code to use more C stdlib primitives.
>> The question is whether these wrappers are worth adding to
>> core.stdc.stdio.
>>
>
> That's the main question. There's only a limited amount of stdc
> functions which can be wrapped in a safe way and std.stdio etc. are
> already kind of a safe wrapper. And it's also important to get these
> wrappers right and make sure they don't introduce memory safety bugs.
I see it as increased opportunity to rely on simple manually checkable
low-level functions, both in Phobos and outside it. It seems there's
merit in that.
Andrei
More information about the Digitalmars-d
mailing list