On 2/8/15 5:16 AM, John Colvin wrote:
> On Sunday, 8 February 2015 at 12:43:38 UTC, FG wrote:
>> On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
>>> Indeed we have no safe way to wrap free.
>>
>> How about this to prevent double free:
>>
>> Wrapped malloc keeps a static thread-local lookup structure for
>> successful allocations (if having to release memory from the same
>> thread is an acceptable requirement).
>>
>> Wrapped free looks up the pointer in that lookup structure and, if
>> found, frees memory, removes the lookup entry and sets the argument of
>> the call to zero (if it was a pointer) or sets its length and ptr to
>> zero (if it was a dynamic array).
>>
>> It's not completely safe, but for that GC would have to be used instead.
>
> I don't have any data, but I'd image most double-frees come from
> multiple references to the same data, not repeated calls to free on the
> same reference.

I think the same. In C++ circles zeroing the pointer after freeing is considering an antipattern - what with false sense of security etc. -- Andrei

On Saturday, 7 February 2015 at 23:50:55 UTC, Andrei Alexandrescu wrote:
> I was looking into ways to make core.stdc safer. That should be relatively easy to do by defining a few wrappers. For example:
>
> int  setvbuf(FILE* stream, char* buf, int mode, size_t size);
>
> is unsafe because there's no relationship between buf and size. But this is fine:
>
> @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);
> }
>
> Another example is:
>
> int stat(in char*, stat_t*);
>
> which may start reading through random memory if the string is not zero-terminated. Again, the solution is here to ensure the string does have a terminating zero:
>
> @trusted int stat(in char[] name, stat_t* p)
> {
>     if (isZeroTerminated(name)) return stat(name.ptr, p);
>     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.
>
>
> Thanks,
>
> Andrei

I think this is crucial if we want to keep actual Phobos sources easily review-able within your requirements. There is a good value in having `core.stdc` to map C headers 1-to-1 though.

Would you consider separate `core.safestdc` package tree where such wrappers could be put on per need basis (duplicating tree structure of core.stdc modules internally)

On 2/9/15 1:39 AM, Dicebot wrote:
>
> I think this is crucial if we want to keep actual Phobos sources easily
> review-able within your requirements. There is a good value in having
> `core.stdc` to map C headers 1-to-1 though.
>
> Would you consider separate `core.safestdc` package tree where such
> wrappers could be put on per need basis (duplicating tree structure of
> core.stdc modules internally)

Walter opposes this on grounds of increased maintenance burdens. He points out (rightly imho) that we better focus on the higher-level primitives present in Phobos. -- Andrei

On Monday, 9 February 2015 at 17:45:09 UTC, Andrei Alexandrescu wrote:
> On 2/9/15 1:39 AM, Dicebot wrote:
>>
>> I think this is crucial if we want to keep actual Phobos sources easily
>> review-able within your requirements. There is a good value in having
>> `core.stdc` to map C headers 1-to-1 though.
>>
>> Would you consider separate `core.safestdc` package tree where such
>> wrappers could be put on per need basis (duplicating tree structure of
>> core.stdc modules internally)
>
> Walter opposes this on grounds of increased maintenance burdens. He points out (rightly imho) that we better focus on the higher-level primitives present in Phobos. -- Andrei

I foresee certain stdc-based primitives being duplicated over and over again as nested functions - in scope of complying with "minimal @trusted function that exposes @safe API" rule.

On 2/9/15 9:47 AM, Dicebot wrote:
> I foresee certain stdc-based primitives being duplicated over and over
> again as nested functions - in scope of complying with "minimal @trusted
> function that exposes @safe API" rule.

Would be nice to encapsulate them in Phobos on a case basis. -- Andrei

On 2/8/2015 8:32 AM, Andrei Alexandrescu wrote:
> I think the same. In C++ circles zeroing the pointer after freeing is
> considering an antipattern - what with false sense of security etc. -- Andrei

What worked for me was using a free() that overwrote the free'd memory with 0xFEFEFEFE or something like that. Worked great for finding bugs.

These days, valgrind does an even better job.

On Monday, 9 February 2015 at 17:45:09 UTC, Andrei Alexandrescu wrote:
> On 2/9/15 1:39 AM, Dicebot wrote:
>>
>> I think this is crucial if we want to keep actual Phobos sources easily
>> review-able within your requirements. There is a good value in having
>> `core.stdc` to map C headers 1-to-1 though.
>>
>> Would you consider separate `core.safestdc` package tree where such
>> wrappers could be put on per need basis (duplicating tree structure of
>> core.stdc modules internally)
>
> Walter opposes this on grounds of increased maintenance burdens. He points out (rightly imho) that we better focus on the higher-level primitives present in Phobos. -- Andrei

Please don't waste your limited resource on this. When people use core.stdc they know what they are doing and take full responsibility of the consequence. If they want safety or nice APIs they wouldn't be using these functions in the first place.