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