473,890 Members | 1,381 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

The illusion of "portabilit y"

In this group there is a bunch of people that call themselves 'regulars'
that insist in something called "portabilit y".

Portability for them means the least common denominator.

Write your code so that it will compile in all old and broken
compilers, preferably in such a fashion that it can be moved with no
effort from the embedded system in the coffe machine to the 64 bit
processor in your desktop.

Sure, you can do that. But as you know, there is no free lunch.
You pay for that "portabilit y" by missing all the progress done
since 1989 in C.

Note that there is objectively speaking not a single useful
program in C that can be ported to all machines that run the
language.

Not even the classic

int main(void) { printf("hello\n ");}

Why?

For instance, if we take that program above and we want to
know if our printf did write something to stdout, we have to write
int main(void) {
int r=printf("hello \n");
if (r < 0) {
// what do we do here ???
}
}

The error code returned by printf is nowhere specified. There is no
portable way for this program to know what happened.

Since printf returns a negative value for an i/o error OR for a
format error in the format string there is no portable way to
discriminate between those two possibilitiess either.

Obviously, network i/o, GUIs, threads, and many other stuff essential
for modern programming is completely beyond the scope of "standard C"
and any usage makes instantly your program non portable.

This means that effectively 100% of real C software is not portable to
all machines and that "portabilit y" is at best a goal to keep in
mind by trying to build abstraction layers, but no more.

This is taken to ridiculous heights with the polemic against C99, by
some of those same 'regulars'.

They first start yelling about "Standard C", and then... they do not
mean standard C but some other obsolete standard. All that, in the name
of "portabilit y".

Who cares about portability if the cost is higher than "usability"
and easy of programming?
jacob

Jul 31 '06 #1
93 4038
jacob navia said:
In this group there is a bunch of people that call themselves 'regulars'
that insist in something called "portabilit y".
The term "regulars" is a common one to describe those who frequent a forum,
whether it be an IRC channel, a newsgroup, or whatever. You yourself are a
"regular" in comp.lang.c, whether you realise it or not.
Portability for them means the least common denominator.
Wouldn't it be better to ask "them" (whoever "they" are) what they mean by
portability, than to assume it? It is quite likely that the word is used in
slightly different ways by various people; it's not a very portable word.

<snip>
Sure, you can do that. But as you know, there is no free lunch.
You pay for that "portabilit y" by missing all the progress done
since 1989 in C.
There isn't all that much progress in C. What did C99 give us? Mixed
declarations? Sugar. // comments? More sugar. VLAs? More sugar. Compound
literals - sure, they might come in handy one day. A colossal math library?
Hardly anyone needs it, and those who do are probably using something like
Matlab anyway.

The real progress has been in the development of third-party libraries, many
of which are at least a bit cross-platform.
Note that there is objectively speaking not a single useful
program in C that can be ported to all machines that run the
language.
So what should I do with all mine? Delete them? Dream on.
Not even the classic

int main(void) { printf("hello\n ");}

Why?
Because the behaviour is undefined. Sheesh.
Obviously, network i/o, GUIs, threads, and many other stuff essential
for modern programming is completely beyond the scope of "standard C"
and any usage makes instantly your program non portable.
Well, it certainly makes your program /less/ portable. I use wrappers around
sockets so that I at least have portability across the Win32/Linux divide.
This means that effectively 100% of real C software is not portable to
all machines and that "portabilit y" is at best a goal to keep in
mind by trying to build abstraction layers, but no more.
Portability is itself an abstraction, and a rather fuzzy one at that. There
is a lot of grey in between "portable" and "non-portable".
This is taken to ridiculous heights with the polemic against C99, by
some of those same 'regulars'.
There isn't any polemic against C99. You have misunderstood. The position of
at least some of the clc regs is that C99 will be just fine - when it
arrives. But it hasn't yet arrived in sufficient volumes to make the switch
from C90 worthwhile.
They first start yelling about "Standard C", and then... they do not
mean standard C but some other obsolete standard. All that, in the name
of "portabilit y".
Well, I'd rather conform to an obsolete standard that is supported by just
about all current C compilers, rather than to a standard that is not.
Who cares about portability if the cost is higher than "usability"
and easy of programming?
It's a trade-off, obviously. Some people will value portability more than
others. Those who don't value it very highly will wander off to newsgroups
dealing with their compiler, OS, or whatever. Those who do value it highly
tend to stick around here. Those who value it highly but who must also use
implementation-specific tricks on occasion can get the best of both worlds
- high quality platform-independent advice here, and platform-specific
advice in a platform-specific group. Sounds sensible to me.

--
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)
Jul 31 '06 #2
jacob navia posted:
In this group there is a bunch of people that call themselves 'regulars'
that insist in something called "portabilit y".

Agreed.

Portability for them means the least common denominator.

"Portabilit y" means "code which must compile successfully with every
compiler, and behave appropriately on all platforms".

Write your code so that it will compile in all old and broken
compilers, preferably in such a fashion that it can be moved with no
effort from the embedded system in the coffe machine to the 64 bit
processor in your desktop.

I'd aim for such.

Sure, you can do that. But as you know, there is no free lunch.
You pay for that "portabilit y" by missing all the progress done
since 1989 in C.

Present(verb) arguments in support of this statement -- I would like to
debate this with you.

Note that there is objectively speaking not a single useful
program in C that can be ported to all machines that run the
language.

If you're talking about GUI programs, then perhaps yes.

But the actual core algorithmic code can be kept fully portable. I've
written programs where all the core code is fully portable.

Not even the classic

int main(void) { printf("hello\n ");}

Why?

For instance, if we take that program above and we want to
know if our printf did write something to stdout, we have to write
int main(void) {
int r=printf("hello \n");
if (r < 0) {
// what do we do here ???
}
}

The error code returned by printf is nowhere specified. There is no
portable way for this program to know what happened.

Nor would I care what happened. If a system can't reliably print a few
miserable characters to the screen, then I wouldn't waste electricity by
plugging it in.

Since printf returns a negative value for an i/o error OR for a
format error in the format string there is no portable way to
discriminate between those two possibilitiess either.

It's the programmer's responsibility to ensure that the format string isn't
corrupt. (Nonetheless, my own compiler warns of such an error.)

Obviously, network i/o, GUIs, threads, and many other stuff essential
for modern programming is completely beyond the scope of "standard C"
and any usage makes instantly your program non portable.

Only the part of the program which deals with GUI, threads, etc.

The underlying algorithms can be (and should be where possible) fully
portable.

This means that effectively 100% of real C software is not portable to
all machines and that "portabilit y" is at best a goal to keep in
mind by trying to build abstraction layers, but no more.

Again, you're only talking about system calls.

Many times, I have written a program in fully portable code (in C++
albeit), and then progressed to write a platform-specific interface.

The core of my code remains fully portable.

Lately, I've begun to use GUI packages which one can use to compile
programs for systems such as Windows, Linux, Mac OS.

--

Frederick Gotham
Jul 31 '06 #3
Richard Heathfield a écrit :
There isn't all that much progress in C. What did C99 give us?
True, C99 didn't really advance the language that much, but it has some
good points. Anyway, if we are going to stick to standard C, let's agree
that standard C is Standard C as defined by the standards comitee.
Mixed declarations? Sugar.
// comments? More sugar. VLAs? More sugar.

And what do you have against sugar?
You drink your coffee without it?

I mean, C is just syntatic sugar for assembly language. Why
not program in assembly then?

Mixed declarations are a progress in the sense that they put the
declaration nearer the usage of the variable, what makes reading
the code much easier, specially in big functions.

True, big functions are surely not a bright idea, but they happen :-)

I accept that this is not a revolution, or a really big progress in C
but it is a small step, what is not bad.

VLAs are a more substantial step since it allows to allocate precisely
the memory the program needs without having to over-allocate or risk
under allocating arrays.

Under C89 you have to either:
1) allocate memory with malloc
2) Decide a maximum size and declare a local array of that size.

Both solutions aren't specially good. The first one implies using malloc
with all associated hassle, and the second risks allocating not enough
memory. C99 allows you to precisely allocate what you need and no more.
Compound literals - sure, they might come in handy one day.
They do come handy, but again, they are not such a huge progress.
A colossal math library?
Hardly anyone needs it, and those who do are probably using something like
Matlab anyway.
Maybe, maybe not, I have no data concerning this. In any case it
promotes portability (yes, I am not that stupid! :-) since it
defines a common interface for many math functions. Besides the control
you get from the abstracted FPU is very fine tuned.

You can portably set the rounding mode, for instance, and many other
things. In this sense the math library is quite a big step from C99.
The real progress has been in the development of third-party libraries, many
of which are at least a bit cross-platform.
That is a progress too, but (I do not know why) we never discuss them
in this group.

Maybe what frustrates me is that all this talk about "Stay in C89, C99
is not portable" is that it has taken me years of effort to implement
(and not all of it) C99 and that not even in this group, where we should
promote standard C C99 is accepted as what it is, the current standard.

I mean, each one of us has a picture of what C "should be". But if we
are going to get into *some* kind of consensus it must be the published
standard of the language, whether we like it or not.

For instance the fact that main() returns zero even if the programmer
doesn't specify it I find that an abomination. But I implemented that
because it is the standard even if I do not like it at all.
standard C
Jul 31 '06 #4
On 2006-07-31, jacob navia wrote:
In this group there is a bunch of people that call themselves 'regulars'
that insist in something called "portabilit y".

Portability for them means the least common denominator.
Portability means the highest possible return for your effort.
Write your code so that it will compile in all old and broken
compilers, preferably in such a fashion that it can be moved with no
effort from the embedded system in the coffe machine to the 64 bit
processor in your desktop.

Sure, you can do that. But as you know, there is no free lunch.
You pay for that "portabilit y" by missing all the progress done
since 1989 in C.
There's surprisingly little that makes programming C99 better than C89.
Note that there is objectively speaking not a single useful
program in C that can be ported to all machines that run the
language.
That's strange. I have programs that I first wrote 20 years ago on
the Amiga, that I have compiled and run successfully, without any
changes, on MS-DOS, SunOS 4, FreeBSD, NetBSD, BSDi, and GNU/Linux.

I expect they would compile and execute successfully on any
standard C implementation.

--
Chris F.A. Johnson, author | <http://cfaj.freeshell. org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence
Jul 31 '06 #5
Frederick Gotham a écrit :
>>Sure, you can do that. But as you know, there is no free lunch.
You pay for that "portabilit y" by missing all the progress done
since 1989 in C.

Present(verb) arguments in support of this statement -- I would like to
debate this with you.

1) VLAs allow you to precisely allocate the memory the program needs
instead of using malloc (with all its associated problems) or having
to decide a maximum size for your local array, allocating too much
for most cases.

int fn(int n)
{
int tab[n];
}

allocates JUST what you need AT EACH CALL.

2) The math library is improved BIG time.
2A) You can portably set the rounding mode for instance, what you
could never do in C89 without using some compiler specific
stuff.
2B) Many new math functions allow you to reduce the number of
compiler dependent stuff in your code.

2C) The generic math feature allows you to change the precision
used by your program easily.
3) Mixing declarations and code allows you to declare variables
near the usage of it, making code more readable.

This are some points. There are others.

Jul 31 '06 #6
Chris F.A. Johnson a écrit :
>>Note that there is objectively speaking not a single useful
program in C that can be ported to all machines that run the
language.


That's strange. I have programs that I first wrote 20 years ago on
the Amiga, that I have compiled and run successfully, without any
changes, on MS-DOS, SunOS 4, FreeBSD, NetBSD, BSDi, and GNU/Linux.

I expect they would compile and execute successfully on any
standard C implementation.
The Amiga system is not an embedded system, and it is many ways very
similar to other command line environments.

I am not telling you that portable programs do not exists or that
it is not worthwhile trying to attain some degree of independence
from the underlying system. I am telling you that (as everything)
portability has some associated COST!
Jul 31 '06 #7

jacob navia wrote:
In this group there is a bunch of people that call themselves 'regulars'
that insist in something called "portabilit y".

Portability for them means the least common denominator.
It primarily means that conforming compilers have been implemented on a
wide variety of hardware and OS combinations, so that conforming code
on one platform can be expected to behave the same on any other
platform.

Secondarily, it means structuring your code so that it supports
multiple platforms concurrently with minimal effort, which I've had to
do on numerous occasions (the most painful being classic MacOS,
Solaris, and Windows 3.1).

And as far as supporting the "least common denominator", it's not my
fault that Microsoft went out of its way to make it nigh impossible to
code for Windows and *anything else* by "extending" C to such a
ridiculous degree. Nor is it my fault that the bulk of the lossage was
on the Windows side.
>
Write your code so that it will compile in all old and broken
compilers, preferably in such a fashion that it can be moved with no
effort from the embedded system in the coffe machine to the 64 bit
processor in your desktop.
What "old and broken" compilers are you referring to, jacob?
Sure, you can do that. But as you know, there is no free lunch.
You pay for that "portabilit y" by missing all the progress done
since 1989 in C.
Really? How so?
Note that there is objectively speaking not a single useful
program in C that can be ported to all machines that run the
language.
I beg to differ; I've written them. It *is* possible to write useful,
conforming apps. Not everything needs to run through a GUI.
Not even the classic

int main(void) { printf("hello\n ");}

Why?

For instance, if we take that program above and we want to
know if our printf did write something to stdout, we have to write
int main(void) {
int r=printf("hello \n");
if (r < 0) {
// what do we do here ???
}
}

The error code returned by printf is nowhere specified. There is no
portable way for this program to know what happened.
That's only sort of true; the return value is EOF if an error occurs,
otherwise the value is not EOF. So rewrite the above as

int main(void)
{
int r = printf("hello\n ");
if (r == EOF)
{
/* handle error */
}

return 0;
}
Since printf returns a negative value for an i/o error OR for a
format error in the format string there is no portable way to
discriminate between those two possibilitiess either.

Obviously, network i/o, GUIs, threads, and many other stuff essential
for modern programming is completely beyond the scope of "standard C"
and any usage makes instantly your program non portable.
Which is why you wrap those sections.

Abstraction is a Good Thing, anyway.
This means that effectively 100% of real C software is not portable to
all machines and that "portabilit y" is at best a goal to keep in
mind by trying to build abstraction layers, but no more.

This is taken to ridiculous heights with the polemic against C99, by
some of those same 'regulars'.

They first start yelling about "Standard C", and then... they do not
mean standard C but some other obsolete standard. All that, in the name
of "portabilit y".

Who cares about portability if the cost is higher than "usability"
and easy of programming?
Talk to me when you've had to support Linux, MacOS, Windows, and MPE
concurrently.

Jul 31 '06 #8
jacob navia <ja***@jacob.re mcomp.frwrites:
Frederick Gotham a écrit :
>>>Sure, you can do that. But as you know, there is no free lunch.
You pay for that "portabilit y" by missing all the progress done
since 1989 in C.
Or you pay for a few C99-specific features by losing a significant
degree of portability.

As many of us have been saying for a very long time, it's a tradeoff,
and different users will make different decisions about that tradeoff.
Pretending that it isn't, or that the choice is obvious, is
disingenuous.
>Present(verb ) arguments in support of this statement -- I would like
to debate this with you.

1) VLAs allow you to precisely allocate the memory the program needs
instead of using malloc (with all its associated problems) or having
to decide a maximum size for your local array, allocating too much
for most cases.

int fn(int n)
{
int tab[n];
}

allocates JUST what you need AT EACH CALL.
Yes. One cost is that there is no mechanism for handling allocation
failures. If I use malloc(), I can check whether it returned a null
pointer, and perhaps do something to handle the error (I can at least
shut down the program cleanly). With a VLA, if the allocation fails,
I get undefined behavior. In most environments, I'd expect this to
abort the program with an error message (not giving me a chance to do
any final cleanup) -- but the C99 standard allows arbitrarily bad
behavior.
2) The math library is improved BIG time.
2A) You can portably set the rounding mode for instance, what you
could never do in C89 without using some compiler specific
stuff.
2B) Many new math functions allow you to reduce the number of
compiler dependent stuff in your code.

2C) The generic math feature allows you to change the precision
used by your program easily.
I don't do much math programming, so I don't know how useful that is.

As a practical matter, this depends on a C99-conforming runtime
library, which is often a separate issue from the conformance of the
compiler.
3) Mixing declarations and code allows you to declare variables
near the usage of it, making code more readable.
I agree that it's a nice feature, but it's easy to work around it when
it's missing. (Some people prefer not to mix declarations and
statements, thinking that keeping them separate improves program
structure; I don't necessarly agree, but I can see the point.)

Incidentally, the word "code" is ambiguous; it often refers to
everything in a C source files, not just statements. "Mixing
declarations and statements" is clearer.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 31 '06 #9
Frederick Gotham <fg*******@SPAM .comwrites:
jacob navia posted:
[...]
>Not even the classic

int main(void) { printf("hello\n ");}

Why?

For instance, if we take that program above and we want to
know if our printf did write something to stdout, we have to write
int main(void) {
int r=printf("hello \n");
if (r < 0) {
// what do we do here ???
}
}

The error code returned by printf is nowhere specified. There is no
portable way for this program to know what happened.


Nor would I care what happened. If a system can't reliably print a few
miserable characters to the screen, then I wouldn't waste electricity by
plugging it in.
[...]

Several points.

What screen?

Both programs above invoke undefined behavior, because they both call
printf() with no prototype in scope. The fix is to add
"#include <stdio.h>" to the top of each.

printf() *can* fail. For example, what if the program's stdout is
redirected (in some system-specific manner) to a disk file, and the
file system has run out of space? If you check the result of printf()
for errors, there are several things you can do. You can try to print
an error message to stderr, which may succeed even if printing to
stdout has failed. Or you can just abort the program with
"exit(EXIT_FAIL URE);".

Or, as most programs do, you can ignore the error and blindly continue
running. (I admit this is what I usually do myself.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 31 '06 #10

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

Similar topics

3
2655
by: Jonathan Mcdougall | last post by:
I started using boost's filesystem library a couple of days ago. In its FAQ, it states "Wide-character names would provide an illusion of portability where portability does not in fact exist. Behavior would be completely different on operating systems (Windows, for example) that support wide-character names, than on systems which don't (POSIX). Providing functionality that appears to provide portability but in fact
35
5506
by: Sunil | last post by:
Hi all, I am using gcc compiler in linux.I compiled a small program int main() { printf("char : %d\n",sizeof(char)); printf("unsigned char : %d\n",sizeof(unsigned char)); printf("short : %d\n",sizeof(short)); printf("unsigned short : %d\n",sizeof(unsigned short)); printf("int : %d\n",sizeof(int));
0
9980
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9829
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
11236
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
10836
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
10926
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
9643
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7172
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
6064
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4278
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.