April 10, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 10-Apr-2014 16:22, Daniel Murphy пишет: > "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; Calls postblit/dtor etc.? What I if I need bitwise assignment? (which is what memcpy is all about) Yes, and with CTFE please. See even std.algo.move and std.algo.swap... > foreach(ref v; arr) > v = 0; Same but also sucks performance-wise. There is a reason Phobos is littered with carefully laid out special cases around C-runtime stuff. -- Dmitry Olshansky |
April 10, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | On Thu, 10 Apr 2014 16:13:31 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> 10-Apr-2014 16:22, Daniel Murphy пишет:
>> "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;
>
> Calls postblit/dtor etc.? What I if I need bitwise assignment? (which is what memcpy is all about)
> Yes, and with CTFE please.
> See even std.algo.move and std.algo.swap...
>
>> foreach(ref v; arr)
>> v = 0;
>
> Same but also sucks performance-wise.
> There is a reason Phobos is littered with carefully laid out special cases around C-runtime stuff.
I think a simple set of functions would be sufficient. It wouldn't even be that complex.
core.memops
-Steve
|
April 11, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | On Wednesday, 9 April 2014 at 12:38:20 UTC, monarch_dodra wrote: > 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. This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation: http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist |
April 11, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Anderson | On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote: > This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation: > > http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist Oops, broken link. http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx |
April 11, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Anderson | On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote: > This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation: > > http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist I just wrote this as a rough draft. I'll make "formal" announcement for it sometime soon, if initial feedback is positive. http://wiki.dlang.org/DIP59 |
April 11, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | On Friday, 11 April 2014 at 20:25:21 UTC, monarch_dodra wrote:
> On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote:
>> This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation:
>>
>> http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist
>
> I just wrote this as a rough draft. I'll make "formal" announcement for it sometime soon, if initial feedback is positive.
>
> http://wiki.dlang.org/DIP59
I know :). We #d IRC users see all! (Vladimir Panteleev's DFeed bot announces basically everything going on everywhere in D).
|
April 12, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 12-Apr-2014 00:25, monarch_dodra пишет: > On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote: >> This list of secure alternatives to C functions Microsoft has would >> probably be a good source of inspiration when deciding what functions >> should be considered for reimplementation: >> >> http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist > > I just wrote this as a rough draft. I'll make "formal" announcement for > it sometime soon, if initial feedback is positive. > > http://wiki.dlang.org/DIP59 Some thoughts. Provide only bitwise comparison, search etc. It's the only case that can reliably benefit from SIMD or hand-written ASM, has problem with CTFE support, etc. Then requiring that T be a POD or built-in type is fine IMHO. Maybe go for copy ---> rawCopy, find --> rawFind (i.e. model after std.algorithm) rather then mimicking C functions. This way we are open to a superset of C-runtime ;) -- Dmitry Olshansky |
Copyright © 1999-2021 by the D Language Foundation