On Wednesday, 9 April 2014 at 12:12:35 UTC, Mike wrote:
> On Wednesday, 9 April 2014 at 11:50:13 UTC, Daniel Murphy wrote:
>> "Mike"  wrote in message news:iflykgpsrmdbfhuwzqtp@forum.dlang.org...
>>
>>> So, my question remains:  If I'm porting D to a platform that has no C library, shouldn't a public, supported function that copies memory be added in the D Runtime?
>>
>> What platform doesn't have a C library?  And you can always cast arrays to ubyte[] before assigning to avoid postblit.
>
> My custom, bare-metal, D-only platform has no C library, nor will it ever.  And, Yes, I know I can cast, but should I?
>
> memcpy is used quite often in Phobos.  Here's a small sample from std.array:
>
> void trustedMemcopy(T[] dest, T[] src) @trusted
> {
>     assert(src.length == dest.length);
>     if (!__ctfe)
>         memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>     else
>     {
>         dest[] = src[];
>     }
> }
>
> You could ask the same question there, "Why isn't a cast used instead?" and remove the dependency on the C library.
>
> So far, it seems D has only been used on one subset of computer systems that happen to have a C library, but some of us our trying to break some new ground with D.  I'm challenging the "D is only useful on PCs with a C library" bias and looking to see if D has the will to stand on its own two feet instead of leaning on C.

I think arguably, there should be D equivalents of the C runtime functions, if only for the added safety of slices (for example, memchr could be 100% certifiably safe), and to avoid the rampant deduplication of things as in the above, because of CTFE.

These may or may not use the C-runtime library. But at that point, it would become a "druntime implementation detail", rather than rampant usage throughout phobos.

"Mike"  wrote in message news:nxretodrkqizyiukwpze@forum.dlang.org...

> My custom, bare-metal, D-only platform has no C library, nor will it ever. And, Yes, I know I can cast, but should I?

Ah.

> So far, it seems D has only been used on one subset of computer systems that happen to have a C library, but some of us our trying to break some new ground with D.  I'm challenging the "D is only useful on PCs with a C library" bias and looking to see if D has the will to stand on its own two feet instead of leaning on C.

druntime and phobos both assume a c library is present, and this is a very safe assumption to make.

It's like assuming that bytes are 8 bits - you can certainly create platforms where this is true but those uses are not worth worrying about.

For a bare metal runtime that doesn't support C, it makes sense to only have a single runtime and add all the needed D and C runtime functions there.

So:
> It seems the D Runtime and Phobos also often make use of memcpy and memset, but they do so through core.stdc which doesn't appear to be part of the D Runtime.  Was this just a matter of convenience or thoughtful design?  I'm guessing the former based on the fact that core.stdc is not in the official language reference.

I don't think you can read that much into the lack of documentation.  I think it's a combination of "these are already documented on other sites" + "these are discourages" + "copying documentation has licensing issues".  The interface to the c library is a part of druntime and here to stay.

> * Were these methods intentionally omitted from the D Runtime, or just taken for granted since they were so conveniently available in the C standard library?

They were _not_ omitted from druntime, they were exposed though core.stdc. (and other places before that)
An implementation in druntime was not necessary because all platforms druntime targets provide a c runtime.

> * Should they be added to core.memory or some other module and exposed as official, supported, methods of the D Runtime (hopefully changing their names)?

No, they are already exposed via core.stdc.



So, if you want to support the full interface that druntime does, you will need to implement these functions somewhere.  There is no point in adding a second interface to them in upstream druntime. 

"monarch_dodra"  wrote in message news:pdzhmmnjxclrjtkgupoz@forum.dlang.org...

> I think arguably, there should be D equivalents of the C runtime functions, if only for the added safety of slices (for example, memchr could be 100% certifiably safe), and to avoid the rampant deduplication of things as in the above, because of CTFE.

The utility of a 'slightly safer' layer between the C functions and the phobos range-based functions is questionable IMO.  eg in cases where memcpy on arrays is safe, phobos' copy would likely optimize to the exact same code. 

On Wednesday, 9 April 2014 at 12:50:23 UTC, Daniel Murphy wrote:
>> * Were these methods intentionally omitted from the D Runtime, or just taken for granted since they were so conveniently available in the C standard library?
>
> They were _not_ omitted from druntime, they were exposed though core.stdc. (and other places before that)
> An implementation in druntime was not necessary because all platforms druntime targets provide a c runtime.
>
>> * Should they be added to core.memory or some other module and exposed as official, supported, methods of the D Runtime (hopefully changing their names)?
>
> No, they are already exposed via core.stdc.
>

Thank you for your thoughtful answer (although I'm not ready to accept it just yet :-)

Let me ask you this:  From a principled D design point of view, is core.stdc an interface only for ports with a C library, an implementation detail of the current druntime that phobos is circumventing, or an official, supported interface that all complying ports must implement?

If the latter, why is it non-existing in the library reference?

"Mike"  wrote in message news:ycvyulqzunbsuweipais@forum.dlang.org...

> Let me ask you this:  From a principled D design point of view, is core.stdc an interface only for ports with a C library, an implementation detail of the current druntime that phobos is circumventing, or an official, supported interface that all complying ports must implement?

From a principled D design point of view, only targets with a C library are supported.  core.stdc is part of the public interface of druntime (as is everything in core) and not an implementation.

There is no real definition in D for what a 'complying port' is, but many D applications and libraries will not run if you do not implement the commonly-used parts of core.stdc.  Full coverage is likely unrealistic for a bare-metal implementation.

> If the latter, why is it non-existing in the library reference?

Because there is no ddoc for these files, and nobody has gone to the effort to make them show up on the website.  Whatever the original intention, enough code using them exists that removing them will never be an option. They probably should just link to the official c-lib documentation. 

09-Apr-2014 16:56, Daniel Murphy пишет:
> "monarch_dodra"  wrote in message
> news:pdzhmmnjxclrjtkgupoz@forum.dlang.org...
>
>> I think arguably, there should be D equivalents of the C runtime
>> functions, if only for the added safety of slices (for example, memchr
>> could be 100% certifiably safe), and to avoid the rampant
>> deduplication of things as in the above, because of CTFE.
>
> The utility of a 'slightly safer' layer between the C functions and the
> phobos range-based functions is questionable IMO.  eg in cases where
> memcpy on arrays is safe, phobos' copy would likely optimize to the
> exact same code.

Pros:

1. No extra scuffolding for CTFE.
2. Type-safe
3. Optional (non-release, etc.) bounds-checking.
4. Less error prone interface, e.g. memset is a known source of bugs in C, even for tried and true code bases.
5. More flexible, see e.g. memchr as an example.

Cons:
A set of primitives to learn.

-- 
Dmitry Olshansky

"Dmitry Olshansky"  wrote in message news:li5lfd$203s$1@digitalmars.com... 

> Pros:
> 
> 1. No extra scuffolding for CTFE.
> 2. Type-safe
> 3. Optional (non-release, etc.) bounds-checking.
> 4. Less error prone interface, e.g. memset is a known source of bugs in C, even for tried and true code bases.
> 5. More flexible, see e.g. memchr as an example.
> 
> Cons:
> A set of primitives to learn.

I don't know why you'd ever use memcpy/memset when you have:

arr[] = 0;
foreach(ref v; arr)
   v = 0;
etc

On Thursday, 10 April 2014 at 12:22:37 UTC, Daniel Murphy wrote:
> "Dmitry Olshansky"  wrote in message news:li5lfd$203s$1@digitalmars.com...
>
>> Pros:
>> 
>> 1. No extra scuffolding for CTFE.
>> 2. Type-safe
>> 3. Optional (non-release, etc.) bounds-checking.
>> 4. Less error prone interface, e.g. memset is a known source of bugs in C, even for tried and true code bases.
>> 5. More flexible, see e.g. memchr as an example.
>> 
>> Cons:
>> A set of primitives to learn.
>
> I don't know why you'd ever use memcpy/memset when you have:
>
> arr[] = 0;
> foreach(ref v; arr)
>    v = 0;
> etc

Because those are assignments.

"monarch_dodra"  wrote in message news:obksandhskaldxplghme@forum.dlang.org...

> Because those are assignments.

You mean they might call postblit etc?  I'd still rather cast to ubyte[] before assigning than call memset. 

On Thursday, 10 April 2014 at 16:59:27 UTC, Daniel Murphy wrote:
> "monarch_dodra"  wrote in message news:obksandhskaldxplghme@forum.dlang.org...
>
>> Because those are assignments.
>
> You mean they might call postblit etc?  I'd still rather cast to ubyte[] before assigning than call memset.

Yeah, but you can't cast to ubyte with CTFE. So you still end up pulling out boilerplate code "at call site", when you could just "deal with it" it a generic way in a named function.