473,591 Members | 2,872 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

C, really portable?

Is C really portable? And, apologies, but this is possibly a little OT?

In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.

I don't write portable C code - *not only* because, in a 'C sense', I
probably do things that aren't portable - but because for the last x years,
I've written code to run on a number of different platforms. Those apps
have had to make use of system calls, use threads, present nice UIs, .

Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].

Conclusion: Whilst the language is portable, applications are not. And
that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].

Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?
Dec 9 '05 #1
131 6083
pemo said:
Is C really portable?
C isn't portable.
C programs aren't terribly portable - a bit, that's all.
C libraries can be *astoundingly* portable, if done properly.

C the language isn't any more or less portable than English.

Useful C programs can be written which will work in many environments, and
indeed I have written many such myself.

But where C really scores is in the fact that you can write a whole bundle
of stuff that will be useful on any platform whatsoever, and call it a
"library".
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.


If carefully written to abstract any non-portable parts of their
functionality into separate modules, C applications can be extraordinarily
portable. Take 500,000 lines of carefully written code, 5,000 of which are
carefully isolated platform-related stuff, and the rest of which is
straight ISO C. Rewrite those 5,000 every time you hit a new platform.
Takes about four man-weeks to port, instead of eight man-years. Hey presto,
portable Web browser. (Hi Borris.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 9 '05 #2
pemo wrote:
Is C really portable? And, apologies, but this is possibly a little OT?
C is very portable.
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
90%[1] of most apps can be written in portable C leaving only 10% you
have to actually tailor for the target.
I don't write portable C code - *not only* because, in a 'C sense', I
probably do things that aren't portable - but because for the last x years,
I've written code to run on a number of different platforms. Those apps
have had to make use of system calls, use threads, present nice UIs, .
So you isolate those pieces of code in a system specific module.
Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Certainly the bulk of applications have non-standard components, but
that does not mean the bulk of the code has to be non-standard.
Conclusion: Whilst the language is portable, applications are not. And
that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].
Many applications are very portable, requiring just a small amount of
tailoring for specific targets. This can be assisted by using libraries
that are available on multiple targets for the system specific stuff
(e.g. QT or GTK+).

I've written C for an embedded system that I then debugged on a silicon
graphics workstation (with some wrapper code) and some of the code was
then used on another completely different platform.

The code I'm currently working on is destined to run on Windows, Linux
and AIX (not in that order), and the application has previously run on
other systems.
Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?


See above. Many of us here work on software that is required to run on
multiple platforms, and we use techniques that have been around since
before I started programming to do it. Things like modularisation and
keeping all the system specific stuff out of the bulk of the modules.

[1] 75% of all statistics are made up on the spot
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Dec 9 '05 #3
pemo wrote:
Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].

Well... yes since you often have to interact with the OS and
environment. But I don't re-write programs monolithically every time I
start a new project. I "drag&drop" libraries I've written over the
years and just write a new main file for the program.

Conclusion: Whilst the language is portable, applications are not.
And that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].

Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?


This is going to be a long(ish) story...

At my previous company, I've fought hard against people who think like
this. Our products run on a wide variety of different environment, all
with different OSes (some with none), all different CPU families and
all different compilers.

The products range from small 8bit PICs to medium 8bit Z80s to large
16bit 68000 to 486 all the way up to a modern 200Mhz ARM9. But they all
tend to have to do the same jobs - getting data over a serial line,
process and route the data and transmitting the data over serial lines
where necessary. Needless to say, this environment encouraged people to
keep re-inventing the wheel. And my bosses, engineers from the 70s,
thought this was the 'natural' way of doing things.

I believed in the portability of C and was appalled at this set-up.
Especially the re-inventing the wheel part. So I started writing
portable code for 'simple' stuff like CRC16 and base64 encoding etc.
using #ifdefs to select the appropriate implementations for resource
starved systems (PICs on average only have 20 bytes of ram). Then I
moved on to more complex stuff like a Modbus protocol engine.

Then the real struggle began - trying to convince people that this is
the way to go. I've already won converts among my team members since
they find it nice to be able to simply browse through my shared folder
of libraries to get what they needed. Slowly people started to
appreciate the effect of fixing a bug in a file fixes it for all
platforms.

The change in attitude towards writing code resulted in a huge library
of re-usable code. This allowed us to concentrate on adding new
features as well as freed us from being dependent on a single
CPU/platform. When our competitors shifted from 68000's to PPCs we were
able to do the same. When ARM became all the rage in embedded devices
we were able to move our product to it as well.

So, I've written code to work all the way from 4MHz, 8bit CPUs with 20
bytes of ram to 200MHz, 32bit CPUs with 128MB of ram and a hard disk.
The complete programs are obviously not portable since you can't expect
a 1MB program to fit on 1kB of EEPROM. But the code I've written, by
themselves, are portable. main() should ideally be the only
non-portable part of your code.

Dec 9 '05 #4
pemo wrote:
Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].

Well... yes since you often have to interact with the OS and
environment. But I don't re-write programs monolithically every time I
start a new project. I "drag&drop" libraries I've written over the
years and just write a new main file for the program.

Conclusion: Whilst the language is portable, applications are not.
And that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].

Anyway, just a thought, and I wonder if anyone can come up with a counter to
it?


This is going to be a long(ish) story...

At my previous company, I've fought hard against people who think like
this. Our products run on a wide variety of different environment, all
with different OSes (some with none), all different CPU families and
all different compilers.

The products range from small 8bit PICs to medium 8bit Z80s to large
16bit 68000 to 486 all the way up to a modern 200Mhz ARM9. But they all
tend to have to do the same jobs - getting data over a serial line,
process and route the data and transmitting the data over serial lines
where necessary. Needless to say, this environment encouraged people to
keep re-inventing the wheel. And my bosses, engineers from the 70s,
thought this was the 'natural' way of doing things.

I believed in the portability of C and was appalled at this set-up.
Especially the re-inventing the wheel part. So I started writing
portable code for 'simple' stuff like CRC16 and base64 encoding etc.
using #ifdefs to select the appropriate implementations for resource
starved systems (PICs on average only have 20 bytes of ram). Then I
moved on to more complex stuff like a Modbus protocol engine.

Then the real struggle began - trying to convince people that this is
the way to go. I've already won converts among my team members since
they find it nice to be able to simply browse through my shared folder
of libraries to get what they needed. Slowly people started to
appreciate the effect of fixing a bug in a file fixes it for all
platforms.

The change in attitude towards writing code resulted in a huge library
of re-usable code. This allowed us to concentrate on adding new
features as well as freed us from being dependent on a single
CPU/platform. When our competitors shifted from 68000's to PPCs we were
able to do the same. When ARM became all the rage in embedded devices
we were able to move our product to it as well.

So, I've written code to work all the way from 4MHz, 8bit CPUs with 20
bytes of ram to 200MHz, 32bit CPUs with 128MB of ram and a hard disk.
The complete programs are obviously not portable since you can't expect
a 1MB program to fit on 1kB of EEPROM. But the code I've written, by
themselves, are portable. main() should ideally be the only
non-portable part of your code.

Dec 9 '05 #5
sl*******@yahoo .com wrote:

<snip portability discusion>
themselves, are portable. main() should ideally be the only
non-portable part of your code.


No, IMHO main should be portable, the non-portable bits should be in a
platform specific library.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Dec 9 '05 #6
pemo wrote:
Is C really portable? [...]


"Portable" is not a Boolean attribute. Worse, it's not
a one-dimensional attribute. Worst of all, its components
aren't all measurable.

"Portabilit y" comes down to economy: How much time, money,
skull sweat, and caffeine will it take to get your program
working on a machine that hasn't hosted it before? Along with
the effort estimate goes another: How strong is the desire to
have the program work on some particular target system? It's
likely that your tic-tac-toe program would be difficult to get
running on your car's engine control computer, but the chances
that you'd want to do such a thing seem pretty remote.

"Portabilit y" cannot even be assessed entirely from a
study of the code. For example, a program written to the
strictest coding standards and impeccably implemented might
still be "non-portable" to a system with less than 256MB of
memory. (The well-behaved program will, of course, fail
cleanly with a polite message -- but if the program cannot
carry out its intended function, it hasn't been "ported,"
has it?)

So: When we say that something is "portable" we're really
using a sort of shorthand for a whole big bag of imponderables.
"Non-portable" is similarly inexact. In c.l.c. usage, all of
these have been tagged as "non-portable;" I've tried to arrange
them in an approximate order from venial sins to deadly:

- Code that assumes two's complement integers

- Code that assumes a particular character encoding

- Code that assumes a particular endianness

- Code that assumes `int i; int j;' allocates the two
variables in adjacent memory locations

.... and, of course, many more. Clearly there are "portabilit y
threats" of different kinds and magnitudes in such examples;
because c.l.c. is sort of rabid we tend to lose the differences
and tar them all with the same "non-portable" brush.

The really interesting thing, I think, is that it often
turns out that the restrictions on "portable" code are less
stringent than may appear at first. One reason I hang around
c.l.c. is that people keep coming up with more-portable ways
of doing things I'd been using less-portable code for; I usually
don't go back and retrofit my old code, but I say "Aha! Neat!"
and stash the technique in my toolbox for future use.

--
Eric Sosman
es*****@acm-dot-org.invalid
Dec 9 '05 #7
"pemo" <us***********@ gmail.com> wrote:
Is C really portable? And, apologies, but this is possibly a little OT?
...snip...


Others have already given good replies. I would
like to add that "portabilit y" depends more on
the developer's knowledge and goals than on a
particular programming language.

C programs can be portable, when written by
knowledgeable and experienced people with
the intention of making them portable.

When the intent, knowledge (1) or experience
are not there, portability will most likely
also be missing.

One of the best examples of portable code I
ever saw, was a set of cross-development
tools for 8080 processors. (Assembler,
linker & simulator.)
The programs were written in a subset of
Fortran, using only the features know to
be common across several Fortran dialects.
The character set encoding was "discovered "
at run time, translation tables were set
up so that the program could run unchanged
in machines using any character encoding:
ASCII, EIBIC, CDC (forget the name), etc.
Hollerith (character) strings were limited
to one character and arrays used for anything
else.
All the input/output functionality was
encapsulated in a couple of functions, so
any environment dependency that forced a
change here would not affect the rest of
the system.

These and similar techniques can be used in
any language to produce portable code.

-----------

(1) A colleague of mine came to me recently
telling he found a bug in GCC. A code segment
behaved differently in our target system,
(Linux on PPC + GCC) than in his test
environment (Windows + Visual C++).
A few questions revealed that he had just
discovered the amazing fact that the plain C
"char" data type can be signed or unsigned
depending on the implementation.
He has been programming in C & C++ for years,
and carries a business card with the title
"Senior Software Engineer".
I would not expect this gentleman to produce
any portable C code, even if his life depended
on that ...

-----------
Roberto Waltman

[ Please reply to the group, ]
[ return address is invalid. ]
Dec 9 '05 #8
Flash Gordon wrote:
sl*******@yahoo .com wrote:

<snip portability discusion>
themselves, are portable. main() should ideally be the only
non-portable part of your code.


No, IMHO main should be portable, the non-portable bits should be in a
platform specific library.


That's only true if you want the whole program to be protable. As I've
described, that's not my case. The main must often do things that are
not 100% portable, like start threads, initialise libraries etc. For
what I'm doing, it's better to write portable libraries/functions and
be able to re-use them on any platform. Main tend to be very small
anyway, all it usually does is call other libraries, so it's not an
issue to re-write it. But that may not be how others write code, that's
just how I do it.

Dec 9 '05 #9
pemo wrote:
Is C really portable?
No. The standard embodies a portable syntax which exists as subset of
any compliant compiler, but that's exactly as meaningless as you might
suspect it is. For example, I don't believe there exists any pair of C
compilers from different vendors that have exact source space
compatibility.
[...] And, apologies, but this is possibly a little OT?
Well C.L.C. is a group about ANSI standard C. I don't know why, but if
you wish to discuss the actual practice of programming in C you will
have to find some other newsgroup to post in.
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
They're not. Amongst languages in common use today, C is just like
Visual Basic in that there just really isn't any real expectation of
portability on any real world application code. Nearly every other
language in common use today is far more portable than C.
I don't write portable C code [...]
(well practically nobody does so ...)
[...] - *not only* because, in a 'C sense', I
probably do things that aren't portable - but because for the last x years,
I've written code to run on a number of different platforms. Those apps
have had to make use of system calls, use threads, present nice UIs, .
Well, its not just that. The standard says integer overflow is
undefined, right shift is not deterministic, you can't assume 2s
complement math, you can't assume ASCII characters, you can't assume
IEEE 754 floating point, wide-characters are specifically specified
*not* to represent anything deterministic, no code can be considered
re-enterable, parameter computation order is not specified, etc.

Even avoiding system calls, user interfaces and threading, its still
very hard to write portable code in C.
Premise: any decently complex modern application cannot be entirely written
in standard C [meaning, the language without compiler added 'extensions',
and only using the standard libraries]. Or, if it is written in standard C,
then it is 'sub optimal' [and certainly doesn't have a nice UI!].
Yes, but this only addresses system and library function calls. Try
writing a reasonable performing crypto-library in pure C that is
completely portable.
Conclusion: Whilst the language is portable, applications are not.
A subset of the *syntax* is portable. Nothing more.
[...] And
that's why we also often see 'go and ask elsewhere' comments appearing here
[totally reasonable they are too of course].


Of course. This group is incorrectly named (or equivalently has been
taken over by people who have ideas for this group that don't
correspond to the name of it). It should be called comp.lang.c.ans i.
This group does not discuss the practice of C programming.

The exception, of course, is the tremendous leniancy given to people
asking questions about gcc, and giving answers that are specific to
gcc.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Dec 10 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

38
3300
by: Martin Marcher | last post by:
Hi, I've read several questions and often the answer was 'C knows nothing about .' So if C knows that little as some people say, what are the benefits, I mean do other languages know more or is it a benefit that C knows nearly nothing (what I can think about is that C is the largest common divisor defined on most available platforms)?
0
7871
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
8236
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8366
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
7995
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
8227
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
5735
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
3851
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
3893
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2379
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.