[D-runtime] How not to write OS specific code

[Sean Kelly]

If the default is not to define it then the user will get a compile error the first time he tries to use it. I'd love to proactively develop the Posix headers, but they're huge. It's easier to build them out as demand dictates. 

Sent from my iPhone

On Feb 1, 2011, at 6:38 PM, Walter Bright <walter at digitalmars.com> wrote:

> The assert is to force the person porting the header to a new system to check to see what is appropriate for that system. I believe os specific code ought to be proactively written, not defaulted, even if the default is to leave it undefined.
> 
> Making it proactive means the maintainer looking at it knows that yes, it is undefined for system X, rather than being overlooked.
> 
> And I agree that having a default be a particular value is just a land mine waiting to blow the next person's foot off.
> 
> 
> Sean Kelly wrote:
>> 
>> I don't know that the static assert is appropriate, since that stuff is optional, and the convention in the Posix headers is not to have an assert for undefined blocks, but it's no big deal to me either way. The 'else' clause was clearly wrong however.
>> 
>> Sent from my iPhone
>> 
>> On Feb 1, 2011, at 10:55 AM, Walter Bright <walter at digitalmars.com> wrote:
>> 
>>> Found this today in src/core/sys/posix/time.d:
>>> 
>>> version( linux )
>>> {
>>>     enum CLOCK_MONOTONIC        = 1;
>>>     enum CLOCK_MONOTONIC_RAW    = 4; // non-standard
>>>     enum CLOCK_MONOTONIC_COARSE = 6; // non-standard
>>> }
>>> else
>>> {
>>>     enum CLOCK_MONOTONIC        = 4;
>>> }
>>> 
>>> This is WRONG WRONG WRONG.
>>> 
>>> 1. it's wrong for OSX, which does not even define CLOCK_MONOTONIC
>>> 2. there's no guarantee that on "other" operating systems CLOCK_MONOTONIC will be defined, or if it is, that it will be 4.
>>> 3. you only find out there's a problem when something mysterious happens.
>>> 4. cut & pasting declarations from one operating system to another without checking is akin to dropping an anvil on the head of the hapless developer who can't figure out why there are mysterious failures on that other system. The developer then has to go back and hand-check every last one of those declarations.
>>> 
>>> This is not acceptable practice. Declarations for an OS should never be inserted or enabled until they are checked.
>>> 
>>> The corrected version is:
>>> 
>>> version( linux )
>>> {
>>>     enum CLOCK_MONOTONIC        = 1;
>>>     enum CLOCK_MONOTONIC_RAW    = 4; // non-standard
>>>     enum CLOCK_MONOTONIC_COARSE = 6; // non-standard
>>> }
>>> else version (FreeBSD)
>>> {   // time.h
>>>     enum CLOCK_MONOTONIC         = 4;
>>>     enum CLOCK_MONOTONIC_PRECISE = 11;
>>>     enum CLOCK_MONOTONIC_FAST    = 12;
>>> }
>>> else version (OSX)
>>> {
>>>     // No CLOCK_MONOTONIC defined
>>> }
>>> else
>>> {
>>>     static assert(0);
>>> }
>>> 
>>> Note that the assert will trip when a new OS is tried, thus pointing the developer at places that need to be checked.
>> 
>>> _______________________________________________
>>> D-runtime mailing list
>>> D-runtime at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>> 
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>>   
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110201/593fc855/attachment-0001.html>