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