malloc and buffer overflow attacks
russhy
russhy__ at gmail.com
Fri Dec 31 23:07:38 UTC 2021
On Friday, 31 December 2021 at 22:13:15 UTC, Paul Backus wrote:
> On Friday, 31 December 2021 at 21:58:14 UTC, russhy wrote:
>> On Friday, 31 December 2021 at 21:37:56 UTC, russhy wrote:
>>> Allocators should be first class citizen anyways, malloc/free
>>> should not be used directly, not only they are unsafe, they
>>> are most of the time not what people need
>>>
>>> And i hope what will come out of `std.experimental.allocator`
>>> won't be using classes..something light, value, extensible
>>> and made with betterC in mind
>>>
>>> It should be the root of everything that comes out of D, not
>>> something lightly thought
>>>
>>> A base to move forward and be future proof
>>
>> Follow up, it's roten:
>> https://github.com/dlang/phobos/search?q=path%3Astd%2Fexperimental%2Fallocator+exception
>>
>> There are words, and facts, unfortunately..
>
> As far as I can tell, the "uses" of exceptions found by that
> search consist of
>
> 1. Code to handle exceptions thrown by copy constructors and
> postblits.
> 2. Optional features that must be explicitly enabled by the
> programmer at compile-time.
> 3. A try/catch block in GCAllocator.
> 3. Unit-test code.
>
> So, nothing here should block compatibility with BetterC,
> although it might require some `version` blocks to disable the
> runtime-dependent stuff.
Ok great, sounds manageable, i'm starting the work already, we'll
see where that'll go
More information about the Digitalmars-d
mailing list