Re: Thou shalt have no other gods before the ANSI C standard
From: rpl (plinnane3REMOVE_at_NOSPAMyahoo.com)
Date: 02/14/05
- Next message: TC: "Re: Protection via activation / product registration keys"
- Previous message: Tim Peters: "Re: I was right, surrogate factoring proof"
- In reply to: Douglas A. Gwyn: "Re: Thou shalt have no other gods before the ANSI C standard"
- Next in thread: rpl: "Re: Thou shalt have no other gods before the ANSI C standard"
- Reply: rpl: "Re: Thou shalt have no other gods before the ANSI C standard"
- Reply: Douglas A. Gwyn: "Re: Thou shalt have no other gods before the ANSI C standard"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 14 Feb 2005 00:58:31 -0500
Douglas A. Gwyn wrote:
> David Wagner wrote:
>
>> ... to illustrate that not every program has to be written so that
>> it will work on every platform allowed by the C spec. And I'm raising
>> that point because of my suspicion that there is a reasonable middle
>> ground
>> between "must work on every crazy platform allowed by the C spec" and
>> DJB's
>> over-strong assumptions. Does that sound right to you?
>
>
> Something like 99% of typical C code doesn't require
> anything more than enlightenment about portability
> issues to ensure that it *does* work on every
> conforming C implementation. The remainder takes a
> little bit more effort, but not so much that it
> dominates development time. Without the necessary
> understanding, a much smaller fraction of the code
> will port glitch-free.
>
> We don't much need to worry about porting "one-time"
> quick hacks. It is code that might reasonably be
> expected to migrate to more platforms, and
> especially code that might be adopted by others,
> that we should be concerned about. Such code does
> justify investing a modest amount of extra effort
> to prevent problems. Remember the maxim about an
> ounce of prevention.
And I seem to be lost again :( ...
Why do you want to port stuff mechanically ? No access to developers of
the old machine/environment/tasks or new machine/environment/tasks ?
Why do you want to compromise performance on 'A' on the off-chance
somebody would want to port it to 'B' ? And if such a chance existed,
why would I not want to be involved ?
rpl
- Next message: TC: "Re: Protection via activation / product registration keys"
- Previous message: Tim Peters: "Re: I was right, surrogate factoring proof"
- In reply to: Douglas A. Gwyn: "Re: Thou shalt have no other gods before the ANSI C standard"
- Next in thread: rpl: "Re: Thou shalt have no other gods before the ANSI C standard"
- Reply: rpl: "Re: Thou shalt have no other gods before the ANSI C standard"
- Reply: Douglas A. Gwyn: "Re: Thou shalt have no other gods before the ANSI C standard"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]