C portability is a myth

[roman ziak]

I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.

In my opinion, porting the program (so you just take the source code and
recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems anymore, but
there are 100s of different systems running in cell-phones, DVD players,
game consoles etc. And one of the very few programs which would work on
all these platforms is: "loop: goto loop;".

Another point is that real worls compilers almost never comply to the
standards. So even taking the code from one compiler to another and
recompiling is a myth unless we talk about some real simple one-evening
type of apps.

And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ? In my eyes not, because I can probably write it from scratch
in another 500 hours or play with it a little and probably adjust it to
second platform or different compiler way faster.

To be honest ... to how many different plattforms and/or compilers are
you porting your programs in average ?

And please, before you start sending flames, please introduce the group
into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...

 

[roman ziak]

And so I am not only critisizing:

One of my recent mini-projects had to be developed on Win/PC and
recompile and work on PocketPC. ARM does not like to work with unaligned
words as much as Pentium and I used arena allocation for allocation
performance reasons. All it needed was to align arena allocated
structures to 32 bit ...

I guess anybody here can tell stories about endianity ...

 

[Gregory Toomey]

And so I am not only critisizing:

One of my recent mini-projects had to be developed on Win/PC and
recompile and work on PocketPC. ARM does not like to work with unaligned
words as much as Pentium and I used arena allocation for allocation
performance reasons. All it needed was to align arena allocated
structures to 32 bit ...

I guess anybody here can tell stories about endianity ...

Netbsd. written in C, runs of over 50 architectures and has device drivers
independent of architecture.

C is a relatively low level lamnguage. If you don't understand architectures
& alignment then its your problem.

gtoomey

 

[roman ziak]

http://www.netbsd.org/People/developers.html

Did they forget to include you ?

It's easy to talk while others walk.

 

[George Wicks]

Oh, jeez. Sounds like you woke up on the wrong side of the bed
there, sparky.

Gregory's comments still stand.

You have an axe to grind with C? Fine. By the way, your comments
would also apply to C++.

Portability can not take into account all machine dependencies. One
of the likeable features of C is that it has low-level capabilities
even for a high level language. Can it bite you if you use without
being mindful of some of its inherent machine dependencies? Yep, it
sure can, and obviously that's the reason you're in a sour mood.

Realize C is just a tool, and you <can> use a tool the wrong way.


@news20.bellglobal.com:

 

[Walter Roberson]

:And the last but not least point is the justification of portability.
:Say I write app in 500 hours using all possible compiler extensions.
oes it justify to write it perfectly portale and spend 1500 hours
:instead ? In my eyes not, because I can probably write it from scratch
:in another 500 hours or play with it a little and probably adjust it to
:second platform or different compiler way faster.

The programs we work [at my job] typically run into the
person-years range. If we were to re-write them, we would have
the advantage of knowing what -didn't- work [scientific programs
have a pretty high mutation rate when you are exploring to see what
-can- be done], but it would still take a long long time.
It doesn't take us 3 times as long to write it portably in the first
place.

:To be honest ... to how many different plattforms and/or compilers are
:you porting your programs in average ?

It depends greatly on the program. My particular job involves a lot
of systems administration work, wherein I'm writing programs for
my own needs rather than for someone else to use; such programs
only have to work for me, for one platform. I still write them
in portable code, unless I'm writing something that is system
specific (e.g., a program to change which CPU a different process
is locked to).

When I am working on the scientific programming part of my job, then
those programs are for more general use, and I take more special care
to ensure that the programs work on other platforms. Usually 3
platforms in such cases.


:And please, before you start sending flames, please introduce the group
:into your last project of porting the software between platforms. And
:let it not be Win98 -> WinXp ...

Latest.... hmmm, that would be a scientific program to determine
similarity between datasets ["similarity" in this case being a
fairly complex algorithm.] It had two major parts, written by
three completely different people. The first (larger) part had
been written by someone who probably shouldn't have been let near
a keyboard; it had been later modified by the second person, who
was a better programmer but who didn't try many large-scale changes
to the program. I cleaned up the code quite a bit and fixed numerous
bugs along the way. The second (smaller) part of the package was
not written to be portable (or even very maintainable), but it was
portable by the time I was finished with it. I couldn't change the
basic structure -too- much as it was still under active development.

When I was done, the program worked without changes on IRIX,
Solaris, and Linux, with the only conditional compilation being
a small section to determine the system serial number for license
locking purposes; that and one include file was slightly parameterized
to take into account that solaris put some of its types into
slightly different files.


Another team sat down to rewrite the code in "portable" Java.
It took them more than 6 person-years to get to the equivilent of
what I'd done in 8 months part-time, and their "Java is
defined as being portable" code wouldn't run on IRIX (relatively
soon into the project) or Solaris (as the project matured). By
the end of that 6 person years, they had decided to give up on Java
and go for pure C++ -- Java just couldn't give them the speed they
needed for accessing large multidimensional data sets in relatively
arbitrary manners.


When I'm writing (or re-writing) a program, I don't so much
set out to write it portably as I set out to write in what might be
called "generalizations". For example, the compute engine is
seperated from the display engine, and the interface between the
two is not through binary procedure calls but rather via an
ASCII command line interpreter. The display portion of the program
starts by sending the API version that it is expecting to talk to;
the compute engine then formats its outputs to conform to that
API version if it can, or tells the display portion the API ranges
it can handle otherwise. In this way, either section of the
code can be replaced as long as the API is conformed to, and there
are no issues about endian (unless the two parts negotiated
binary transfer, in which case the endian-ness of the data would
be negotiated too.)

As my code progresses [and keep in mind that the end-user requirements
can literally change within 5 minutes], I build more and more
abstraction layers, making the program more and more flexible -- making
it easier and easier to deal with the researcher changing his or her
mind, and making it easier and easier to port. I would be lying if I
said that all the abstraction layers were obvious to me when I started
the project: programming (especially with changing requirments) is
often a process of revelation of hidden order from the apparent
chaos.

 

[Thomas Matthews]

And so I am not only critisizing:

One of my recent mini-projects had to be developed on Win/PC and
recompile and work on PocketPC. ARM does not like to work with unaligned
words as much as Pentium and I used arena allocation for allocation
performance reasons. All it needed was to align arena allocated
structures to 32 bit ...

I guess anybody here can tell stories about endianity ...

Let us say that you are porting code from an 80386 processor to
an AM7TDMI in Big Endian configuration. (BTW, 80386 is Little
Endian).

Given the following common message structure:
struct Message
{
unsigned char command;
unsigned int message_length;
unsigned short checksum;
};
The compiler is allowed to add padding bytes between the fields.
This is from the language specification, regardless of the platform.

Knowing that padding bytes _may_ be added, one cannot
directly transfer this structure in a mirror copy. One
must access the fields directly.

For example, one cannot use fwrite() to serialize the
structure (i.e. send it out). The proper method is to
place each field sequentially into a buffer, then transmit
the buffer. This technique allows for no padding, regardless
of whether the compiler added padding bytes or not.

If you think portability is fun, try dealing with multiple
processors on the same platform that have different endian
or alignment restrictions.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[chrsT]

What I noticed is that your IP address is almost the same, or falls
within the same range of previous posters with this type of message
topic.

My best guess is, that the same person is trying to play to some of
the groups feelings and provoke reactions.

Time to add another anti-flame kill-filter to my nntpclient?

Chris.

 

[Mysidia]

I just read couple articles on this group and it keeps amazing me how

the portability is used as strong argument for language cleanliness.

In my opinion, porting the program (so you just take the source code and
recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems anymore, but
there are 100s of different systems running in cell-phones, DVD

players,

It's definitely possible to write both portable and non-portable user
code in C, and it's almost all about writing clean code.

On the other hand,
to do useful things, i.e. make a GUI program with mouse support,
you have to compromise the automatic portability

But you certainly can write appropriate code for the facilities
which depend on platform, and choose what code to use with #ifdefs.

Try doing this in assembly.

C is not the best at portability, according to the more modern
relative definition of portability...

Java for example is supposed to
provide automatic portability (What you lose in the process is
performance
and some basic capabilities: things you can do portably are limited by
the
high level SDK available, (and sometimes the high level SDK isn't good
enough)

For extreme examples
.... try writing a portable OS or tool in Java that dials out on the
modem or otherwise interacts directly with some piece of hardware
).



-Mysid

 

[Jack Klein]

players,

It's definitely possible to write both portable and non-portable user
code in C, and it's almost all about writing clean code.

On the other hand,
to do useful things, i.e. make a GUI program with mouse support,
you have to compromise the automatic portability

But you certainly can write appropriate code for the facilities
which depend on platform, and choose what code to use with #ifdefs.

Try doing this in assembly.

C is not the best at portability, according to the more modern
relative definition of portability...

Java for example is supposed to
provide automatic portability (What you lose in the process is
performance
and some basic capabilities: things you can do portably are limited by
the
high level SDK available, (and sometimes the high level SDK isn't good
enough)

Except Java provides no portability at all to any platform that isn't
at least 32-bits with a multi-tasking GUI environment. C on the other
hand, does.

For extreme examples
... try writing a portable OS or tool in Java that dials out on the
modem or otherwise interacts directly with some piece of hardware
).

-Mysid

There is a C compiler, or more likely several or dozens, for virtually
every processor architecture in existence, from 8-bit microprocessors
and microcontrollers to 64-bit supercomputers.

No new processor or controller is ever introduced without some C
compiler being available these days. If the manufacturer does not
provide one free or sell it, they will subsidize at least one third
party compiler vendor to produce one.

You can't say that about Java, you can't say that about C++, in fact
you can't say that about any other language at all.

The core of C is the most portable language in existence, has been for
a long time, and will be for a long time to come.

 

[Jack Klein]

I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.

OK, here's my question:

"Are you a troll and an idiot, just a troll, or just an idiot?"

In my opinion, porting the program (so you just take the source code and
recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems anymore, but
there are 100s of different systems running in cell-phones, DVD players,
game consoles etc. And one of the very few programs which would work on
all these platforms is: "loop: goto loop;".

Nonsense, you're talking about either platform-specific things like
GUIs and database access, or hardware specific things like low level
registers.

In computer programming, the core C language is the most portable in
existence. Period. There is no other language that exists on as many
architectures. Period.

 

[Stephen Sprunk]

I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.

In my opinion, porting the program (so you just take the source code
and recompile) is a myth started 20-30 years ago when world consisted
of UNIX systems. Well, world does not consist of UNIX systems
anymore, but there are 100s of different systems running in cell-
phones, DVD players, game consoles etc. And one of the very few
programs which would work on all these platforms is: "loop: goto
loop;".

A portable program should run on all of them.

I'll also note that systems today are much more consistent than they were
20-30 years ago. Byte sizes, memory models, integer representation, etc.
are identical on nearly every modern system -- arguably due to C's influence
on the industry.

Another point is that real worls compilers almost never comply to the
standards. So even taking the code from one compiler to another and
recompiling is a myth unless we talk about some real simple one-evening
type of apps.

Compilers do an excellent job of complying with the standard. What makes
programs unportable are all the extensions and libraries that are available
on some systems and not others. That is not C's fault.

And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ? In my eyes not, because I can probably write it from scratch
in another 500 hours or play with it a little and probably adjust it to
second platform or different compiler way faster.

Writing an unportable program may take you 500 hours, but writing a portable
one would only take 600 hours or so. Trying to port existing code that
wasn't written with the intent of being portable may well take you another
1000 hours, but that's your fault for writing it unportably in the first
place.

To be honest ... to how many different plattforms and/or compilers are
you porting your programs in average ?

And please, before you start sending flames, please introduce the group
into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...

A former employer of mine had a major application that ran just fine on
M68k, MIPS32, MIPS64, PPC32, PPC64, SPARC, IA32, and possibly others I'm
unaware of. It would use an MMU if available or fake one if not. It would
run on a microkernel, as an OS itself, or even as a user-mode Solaris
application. Certain files (in platform-specific directories) were
obviously unportable, but I'd estimate 95% of the code was portable.

In case you think that is a trivial example, the program was in the millions
of lines of source, with around 10,000 developers currently and a
development period of over a decade. Daily builds and test cycles against
all platforms were standard. Portability failures were unheard of because
the coders learned to write portable code. Several of those platforms were
added while I was there and it was almost trivial, requiring only
modifications or additions to files that were explicitly marked as
unportable.

( And no, it's not Windows or some UNIX variant... )

S

 

[roman ziak]

I can only agree that C is probably the first HL language of choice for
most newly introduced CPU platforms.

My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since
plattform is same, regardless on the CPU.

If porting C programs was that easy, then hardware vendors would just
(with little effort) write their Windows drivers so they could be
recompiled under say Linux as the other popular PC platform. They don't
and that's even same CPU.

Why?

Because different platforms need different calls, different data
structures, ...

Portability is possible only when there is at least some common ground.
Standard C library is not enough, because computers communicate (non
standardized in CLIB), display stuff on screen (beside printf not
standardized in CLIB), have threads of execution (not standardized in
CLIB), control external devices etc.

Portability is not property of the language but its implementation.

 

[roman ziak]

Compilers do an excellent job of complying with the standard. What makes

programs unportable are all the extensions and libraries that are available
on some systems and not others.

Very true.

A former employer of mine had a major application that ran just fine on
M68k, MIPS32, MIPS64, PPC32, PPC64, SPARC, IA32, and possibly others I'm
unaware of. It would use an MMU if available or fake one if not. It would
run on a microkernel, as an OS itself, or even as a user-mode Solaris
application. Certain files (in platform-specific directories) were
obviously unportable, but I'd estimate 95% of the code was portable.

In case you think that is a trivial example, the program was in the millions
of lines of source, with around 10,000 developers currently and a
development period of over a decade. Daily builds and test cycles against
all platforms were standard. Portability failures were unheard of because
the coders learned to write portable code. Several of those platforms were
added while I was there and it was almost trivial, requiring only
modifications or additions to files that were explicitly marked as
unportable.

This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.

This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime. Do you actually
think that if the language of choice of your employer was Pascal and
let's assume there would be a conforming Pascal compiler on each of
those plattforms, they would not succeed with the application ?

 

[Walter Roberson]

:I can only agree that C is probably the first HL language of choice for
:most newly introduced CPU platforms.

:My point, however, was that there is certain expense on this
ortability, unlike mentioned Java where portability is inherent since
lattform is same, regardless on the CPU.

Java is not really portable -- it's API has changed too much over
time for that. There are several major components of Java, and you
need to match them closely.

Porting java itself to a new platform takes a fair bit of time and work.
Oh, and Java itself was originally written in C, according to Sun.


:If porting C programs was that easy, then hardware vendors would just
with little effort) write their Windows drivers so they could be
:recompiled under say Linux as the other popular PC platform. They don't
:and that's even same CPU.

You can't do that with Java either.


ortability is possible only when there is at least some common ground.
:Standard C library is not enough, because computers communicate (non
:standardized in CLIB), display stuff on screen (beside printf not
:standardized in CLIB), have threads of execution (not standardized in
:CLIB), control external devices etc.

Several of those things are supposed standardized in Java... but
it's still not really portable.

 

[tomstdenis]

I just read couple articles on this group and it keeps amazing me how

the portability is used as strong argument for language cleanliness.

If C is not portable you had better inform my 100s of users...
Specially the Playstation folk who seem to think the software I wrote
partly in win32/x86, linux/x86_32 and linux/x86_64 will work on their
MIPS based system...

Might want to also talk to the MatrixSSL folk who use it in ARM
platforms and the BitMover folk who use it in about 12 other
platforms...



Tom

 

[tomstdenis]

I can only agree that C is probably the first HL language of choice for
most newly introduced CPU platforms.

My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since
plattform is same, regardless on the CPU.

If porting C programs was that easy, then hardware vendors would just

(with little effort) write their Windows drivers so they could be
recompiled under say Linux as the other popular PC platform. They don't
and that's even same CPU.

Why?

Cuz maybe the WinNT and Linux Kernel don't work the same way? That has
NOTHING todo with the C language...

Now I know for a fact you're just a troll.

BTW Things like GUI and dB access ARE fairly portable. It's called
Motif and MySQL. Heck libs like GTK+ and QT are even fairly portable
[even ported to windows].

So I really think you're [all of]

a) a troll
b) ignorant
c) an ignorant troll

Tom

 

[Mabden]

Another point is that real worls compilers almost never comply to the
standards. So even taking the code from one compiler to another and
recompiling is a myth unless we talk about some real simple one-evening
type of apps.

World. We call it the "real world".

And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ? In my eyes not, because I can probably write it from scratch
in another 500 hours or play with it a little and probably adjust it to
second platform or different compiler way faster.

Portable. We call it portable, not portale.

To be honest ... to how many different plattforms and/or compilers are
you porting your programs in average ?

Platforms. And we port _to_ them "on average" not "in average".

And please, before you start sending flames, please introduce the group
into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...

I ported my Windows game to the Palm OS. It was a total re-write. I'm
thinking about a cellular phone version, but there is no pointer tool
for a cell phone...

 

[jjf]

http://www.netbsd.org/People/developers.html

Did they forget to include you ?

It's easy to talk while others walk.

What does the presence or otherwise of Gregory's name in the
NetBSD developer list have to do with his proof that you are
talking nonsense?

 

[dandelion]

Very true.


This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.

This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime.

Gcc, to name but one, is not proprietary. But you are right. Portability
starts
with good design. Separating model from representation, for instance, or
encapsulation,
tight coherence and loose coupling....

Do you actually think that if the language of choice of your employer was Pascal and
let's assume there would be a conforming Pascal compiler on each of
those plattforms, they would not succeed with the application ?

Actually, no.

If they would use a conforming Pascal compiler, you can forget about
anything dealing with actual hardware, building *large* systems, using
external libraries, etc. The program you *can* write will be fairly
portable, but quite limited. Besides, two different implementations may have
different ideas on what the maximum value for an integer is, what precision
floating points have, etc. All those things so neatly coped with in the
various standard C headers.

Assuming you have some non-conforming implementation (like Turbo-Pascal),
you'd be in worse trouble, since you are limited to *that* specific compiler
and the platforms it supports.

Conforming Pascal is a great language for programming-classes, but not for
actual software development.