Re: C portability is a myth
From: Flash Gordon (spam_at_flash-gordon.me.uk)
Date: 02/18/05
- Next message: G Fernandes: ""token" "token sequence" "scalar variable" "vector" ??"
- Previous message: Flash Gordon: "Re: C portability is a myth"
- In reply to: websnarf_at_gmail.com: "Re: C portability is a myth"
- Next in thread: websnarf_at_gmail.com: "Re: C portability is a myth"
- Reply: websnarf_at_gmail.com: "Re: C portability is a myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 17 Feb 2005 23:59:32 +0000
websnarf@gmail.com wrote:
> Stephen Sprunk wrote:
>
>>Availability is one (of many) components of portability. Nobody is
>>claiming they're equivalent, but they're related.
>
> They are different compontents related by a problem manifested by the C
> language standard. Namnely: can you compile and run a given set of C
> source code. Having a compiler on a platform is supposed to give you
> some hope that its possible, but the path is usually convoluted unless
> the program is extremely trivial (like a Unix text processing utility.)
Strange that when I ported a *complex* application to run under Cygwin
it required minimal effort.
> Look, the distinction is just a matter of english:
>
> When one "ports" a piece of code, one is not talking about the
> solicitation for the availability of a compiler for a given platform.
> One is implicitely assuming there is some other target platform with a
> different compiler, and one engages in the activity of "porting"
> (changing the code -- not installing some compiler.)
And if no such implementation is available then said port is not
possible unless you are prepared to write it. Therefore, when no such
implementation is already available part of the porting process is the
writing of such an implementation.
> When an application becomes "ported", this means that the application
> has been modified (including the rare possibility of no changes.)
> Nobody would say an application becomes "ported" when a new platform or
> compiler becomes available and the sources happen to work on it.
Incorrect. People frequently talk about porting applications where no
code changes are required. In such cases the porting is comparatively
simple, but still requires testing.
However, if we do use your terminology, when you get a Java application
to run on a different system without changing the code you are not
porting it, so the ability to do that has nothing to do with portability
(i.e. the ability to port).
> When one uses a "portability layer" they are not referring to something
> like a "compiler emulator" or cross compiling, or some kind of compiler
> detection. Its usually a library module, or source modification tool
> that makes a body of code be of such a manifestation that it can run on
> multiple platforms more easily irrespective of compiler availability.
Irrelevant.
> If someone generates a "port" it doesn't mean they've made a C compiler
> available to a platform where one didn't exist before. It means
> they've modified their sources in some way to make a piece of code work
> on a platform where it didn't before.
Not entirely true. If there is no C implementation then part of the
porting process would generally be writing a C implementation. It
normally does not involve this simply because it is exceedingly rare to
find any target without a C implementation already available.
> If I am "porting" a piece of code or library, I am not trying to make a
> compiler available on a platform.
Unless there is no such compiler, in which case writing the compiler is
part of the porting process.
> I am just in the process of
> modifying it to make it work on a target platform. A system developer
> might port a compiler or generate one for a new system, but this is a
> port in of itself for the purpose of making a compiler available. For
> example when AMD and SUSE first ported gcc over to AMD64, they didn't
> take credit for "porting" the rest of the open source universe to their
> platform;
No, because the rest also had to be ported. See my comments above about
porting.
> and the ANSI C standard can't take credit for it either --
Yet further down you say the Java standard ports. Showing yourself as
inconsistent.
> because after that was done each application then had to be "ported"
> all over again (because there's no guarantee that they'll work -- you
> have to test it).
The same applies to Java applications. I have already pointed out that I
*have* a Java application that does *not* work in all Java implementations.
> Now if one creates a JVM for a platform (thus making it "available"),
> does that mean they have "ported" all the Java applications onto that
> platform? At best you can say that the Java *standard* ported the
> applications.
Apart from the fact that not all Java applications will necessarily work
on it you mean? See my comment above. However, yes, they could be
considered to have ported all the Java applications that do run without
recompilation.
When my company releases Java code we specify which JVMs it *will* work
on and if someone uses something different then getting it to work it
*their* problem unless they pay us to sort it, and even then we won't
guarantee is *can* be sorted, hence us telling customers that they
*have* to upgrade to the latest version of SCO (although we are moving
away from it).
-- Flash Gordon Living in interesting times. Although my email address says spam, it is real and I read it.
- Next message: G Fernandes: ""token" "token sequence" "scalar variable" "vector" ??"
- Previous message: Flash Gordon: "Re: C portability is a myth"
- In reply to: websnarf_at_gmail.com: "Re: C portability is a myth"
- Next in thread: websnarf_at_gmail.com: "Re: C portability is a myth"
- Reply: websnarf_at_gmail.com: "Re: C portability is a myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
