• Marco Leise (31/31) Oct 17 2014 When I read that error I wondered why anyone would define a
• Sean Kelly (3/3) Oct 17 2014 Its a holdover from when we were trying to eliminate imports in
• Marco Leise (6/9) Oct 17 2014 Alright, I guessed so.

Marco Leise <Marco.Leise gmx.de> writes:

When I read that error I wondered why anyone would define a
function for threads with the same name as a well established
C function. On a closer look it revealed to be just another
name for the same extern(C) memcpy to avoid the import of
core.stdc.string in core.thread:

private
{
    import core.sync.mutex;
    import core.atomic;

    //
    // from core.memory
    //
    extern (C) void  gc_enable();
    extern (C) void  gc_disable();
    extern (C) void* gc_malloc(size_t sz, uint ba = 0);

    //
    // from core.stdc.string
    //
    extern (C) void* memcpy(void*, const void*, size_t);

    //
    // exposed by compiler runtime
    //
    extern (C) void  rt_moduleTlsCtor();
    extern (C) void  rt_moduleTlsDtor();

    alias void delegate() gc_atom;
    extern (C) void function(scope gc_atom) gc_atomic;
}

Well, it is mildly annoying. `private` doesn't really help in
the way the author expected it to work here.

-- 
Marco

"Sean Kelly" <sean invisibleduck.org> writes:

Its a holdover from when we were trying to eliminate imports in 
druntime because of the associated overhead. I'd submit a 
bugzilla about it.

Marco Leise <Marco.Leise gmx.de> writes:

Am Fri, 17 Oct 2014 15:54:27 +0000
schrieb "Sean Kelly" <sean invisibleduck.org>:

 Its a holdover from when we were trying to eliminate imports in 
 druntime because of the associated overhead. I'd submit a 
 bugzilla about it.

Alright, I guessed so.
https://issues.dlang.org/show_bug.cgi?id=13627

-- 
Marco