unnecessary OS redundancy in druntime

[Iain Buclaw via Digitalmars-d]

On 12 Dec 2014 17:15, "Martin Nowak via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On 12/12/2014 04:47 PM, Joakim wrote:
>>
>> I asked about this on github but didn't get a good answer, so I'm asking
>> here.  What's with all the repeated OS blocks in druntime?
>
>
> No, you don't want to accept the answer. That's slightly different than
not getting none.
>
>
>>
https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/posix/unistd.d#L945
>>
>>
https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/posix/netinet/in_.d#L974
>>
>>
https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/posix/arpa/inet.d#L201
>>
>>
>> It seems like pointless repetition and there are many more examples of
>> this, as I keep running into it when adding bionic/Android support.
>> Martin suggested that it would be useful to have a default case that
>> asserts for an unsupported OS, but many of these blocks don't have that
>> either.
>
>
> Because it was written before we spread out to multiple architectures,
and learned hard it is to add something.
>
>
>>
>> Why not just declare them once for Posix and then specialize for a
>> particular OS later on when necessary, as seems to have been done in
>> these instances?
>
>
> We've been through this several times, because the poor guy adding
support for a new OS or arch has the find all the differences through
debugging.
>
>

One of the worst I've hit was a crash deep in the start-up initialisation
of Druntime... caused by a totally not obvious struct size/align mismatch
with Cruntime's pthread.  Along with not wasting a day switching between
druntime and system C headers, having a compile-time error ensures that the
porter has vetted the correctness of the ported declarations and structures.

It may take a while to port all areas, but at least you can be mostly
assured that each step is towards a fully working runtime.

Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141212/a8375318/attachment.html>