Segregating the standard library

Alexander Panek a.panek at brainsware.org
Sat Nov 18 01:41:19 PST 2006


The main problems are printf(), malloc() and similar. Everything else is 
held pretty platform independent, so it can either be just left out or 
be integrated without any worries. Apart from that, a compiler flag like 
GCC comes with one, "-ffreestanding", would be really great.


"-ffreestanding
       Assert that compilation takes place in a freestanding environment.
       This implies -fno-builtin.  A freestanding environment is one in
       which the standard library may not exist, and program startup may
       not necessarily be at "main".  The most obvious example is an OS
       kernel.  This is equivalent to -fno-hosted."

Also, possibility to link ELF files that can be loaded by Grub or 
similar would be great...don't know if that's possible atm with /link/.

Alex


Chris Miller wrote:
> On Fri, 17 Nov 2006 17:47:19 -0500, Daniel Keep 
> <daniel.keep.lists at gmail.com> wrote:
> 
>> * We need to make a clear distinction between the absolute bare-minimum
>> for the compiler and produced programs to function (let's call that the
>> core lib) and everything else (the standard lib.)
>>
>>   The core lib would probably contain things like intrinsics, and
>> anything else necessary (I think that also includes Object
> 
> Agreed.
> 
> The core should allow D to be used for OS development with little 
> effort, and should allow D to be used as a C replacement, only using D's 
> core features and only C's library.
> 
> This would make it a real systems programming language. Right now to 
> achieve this you have to do a bit of implementation-specific hacking.
> 
> There's also a gray area where D itself depends on the GC, such as when 
> using length properties, ~= and ~ operators, and array literals. Perhaps 
> these should just segfault if used only with the D core and no 
> replacement GC.
> 
> - Chris



More information about the Digitalmars-d mailing list