porting vs migrating

[Flash Gordon]

jaysome wrote, On 04/03/07 09:44:

I have this simple Standard C program:

#include <stdio.h>
int main(void)
{
printf("Hello world.\n");
return 0;
}

I copied the source code file from my IBM mainframe to my Windows box.
I compiled it using Microsoft VC++, but I got a lot of warnings:

hello.c(1) : error C2449: found '{' at file scope (missing function
header?)

When I look at the code on my monitor on my IBM mainframe it looks
like "portable" C. I suspect there is a character encoding issue and I
need to "migrate" the code from the IBM mainframe to my PC by using an
EBCDIC-to-ASCII translator, as I seem to recall that the encoding of
the character set is not specified by the C standard.

That is a problem with you not knowing (or deliberately not using) the
correct method to copy text files between systems. You can get
comparable results by copying a binary file where the encoding is
*exactly* specified by copying using the wrong method.

The C standard could not sensibly specify the source character set
because if it did you would find that either on your PC or on your IBM
mainframe you would not be able to use a standard text editor on your C
source files, and that would be just plain stupid.

So try again using one of the correct methods for copying text files,
such as FTP in "ASCII" mode which is explicitly defined for solving this
very problem.

Oh, and your argument would say that exactly NOTHING is portable
(including binary files between machines of the same type running the
same version of the same OS), so it is a completely useless way of
talking about portability.

 

[Flash Gordon]

santosh wrote, On 04/03/07 10:09:

jaysome wrote:


But, this can be called porting or migrating, since it involves no

You corrected this to be "...cannot be called..." in another post.

changes to the source itself, merely to the files that contain them.
Moreover, this is trivial conversion that'll take a few minutes at the
most.

It it takes more than 5 seconds extra (including typing time) then you
should give up on using different systems. Using my preferred tools it
takes no measurable extra time and no thought to get it right, on the
next most likely tools that I would use it takes a lot less than 5 extra
seconds even if I am dealing with several GB of source files, since I
just have to tell it that the files are text and then copy them.

 

[Yevgen Muntyan]

Stan Milam said:


In situations where that's true, it's typically 1% of the code base or
less - and, as you suggest - if you're sensible you've carefully
isolated it to ease rewriting. And in situations where it's false, it's
false anyway.

The reason for my admittedly somewhat provocative reply is that there is
a perception amongst some clcers that you can't write real programs in
100% ISO C. Well, I would agree with the contention that you can't
write /all/ real programs in 100% ISO C, but the subset of programs
that you /can/ write is much, much larger than people realise.

More important is the fact that subset of programs that *are written*
in 100% ISO C is very small. Much, much smaller than of those which
*can* be written in standard C. And stupidity or similar is not the
only reason for this.

This is
probably at least in part because many of them have grown up in a GUI
world - if it don't have gooeys, it ain't really a program - but of
course this perception is utterly false.

In part, certainly. But perhaps people also think programs should be
able to work with directories, spawn processes, use network, poll
files, play music, process signals, people think it's good to do things
like using shared libraries written by others, etc.

Yevgen

 

[Richard Heathfield]

Yevgen Muntyan said:

Richard Heathfield wrote:


More important is the fact that subset of programs that *are written*
in 100% ISO C is very small. Much, much smaller than of those which
*can* be written in standard C. And stupidity or similar is not the
only reason for this.

I am not convinced by your claim.

In part, certainly. But perhaps people also think programs should be
able to work with directories, spawn processes, use network, poll
files, play music, process signals, people think it's good to do
things like using shared libraries written by others, etc.

*Some* programs should certainly be able to do those things - but a
great many have no use whatsoever for them. Why would, say, the
month-end run need to play music? What's the point of letting a
graphics filter worry about a network? How would knowledge of
directories benefit a Diffie-Hellman calculation?

The fact is that directories, multi-threading, networking, and so on, do
tend to make programming a bit more interesting for many people, and so
they tend to see those features as being an integral part of
programming.

 

[Chris Torek]

More important is the fact that subset of programs that *are written*
in 100% ISO C is very small. Much, much smaller than of those which
*can* be written in standard C.

I doubt this is quite what you meant to say. Using the Standard
C grammar as a generative grammar, we can generate an infinite
number of "100% ISO C" programs, at least if we ignore translation
limits.[1] Clearly any finite number -- the number of actual programs
existing in the world today, whether in C or in any other language
-- is much less than infinity.

I think what you meant to say is: let n1 be the number of strictly
conforming C programs (or "100% ISO C", which is not as well defined
as "strictly conforming", not that "strictly conforming" is all
that useful in a practical sense either). Let n2 be the number of
programs that could have been strictly conforming (or "100% ISO",
however we choose to define that) with at most some small tweaks,
perhaps not even giving up any actual functionality.

I will agree, without even seeing any statistics, that n1 < n2.
I think you claim that n1 "much less than" n2 (n1 << n2, in
mathematical notation, rather than C expression notation). I would
have to see statistics -- and a definition for "much less than",
for that matter -- to believe the latter.

And stupidity or similar is not the only reason for this.

Depending on how we define the measure for n2, however, it may be
the primary reason.

-----
[1] Actually, the grammar alone only generates "grammatically
correct" programs; we have to throw away the semantically-invalid
ones. For instance, the grammar will generate, among the infinite
other programs, this one:
int main(void) { int i; j = 42; return 0; }
which is wrong because it never declares "j". (My transfinite math
is a bit weak but I believe the cardinality of both sets -- "all
grammatically correct C programs" and "all semantically correct
C programs" -- is just aleph-null.)

 

[Yevgen Muntyan]

Yevgen Muntyan said:


I am not convinced by your claim.

I didn't think for a single second you would. Anyway, are you saying
that many programs are actually written in standard C? What OS is that,
and what programs? If you will say that there are thousands over
the world, it most certainly will be true. But how many programs
installed on your computer or on my computer are written in standard C?
And how lucky are you if you got to write a program where you don't
need any stuff which isn't in C standard?

*Some* programs should certainly be able to do those things - but a
great many have no use whatsoever for them.

Again, it depends on what "some" and "great many" mean. Of course
your claim is totally true. It's just a bit vague (sure, mine is as
vague too).

Why would, say, the
month-end run need to play music?

Sorry, don't know what "month-end run" is.

What's the point of letting a
graphics filter worry about a network?

No point at all. But I bet there are more programs working with
network than graphic filter *programs*.

How would knowledge of
directories benefit a Diffie-Hellman calculation?

I guess the diffie-hellman binary sitting in your /usr/bin
doesn't need to know about directories. A computer algebra
application which works with user (like reads his files,
performs some calculations) does need to know about directories
often.

Anyway, nobody said every program needs to play music. And
lot of programs which are not written in standard C *can*
be rewritten in standard C. Everybody can implement hash tables
and regular expressions, for instance. But it'd be rather strange
if people actually restricted themselves to standard C just
for standard-C-only sake. You know, POSIX, Unix, libraries,
code reuse, coding cost and all that, aka real life matters.

The fact is that directories, multi-threading, networking, and so on, do
tend to make programming a bit more interesting for many people, and so
they tend to see those features as being an integral part of
programming.

Well, if you are saying that people tend to add needless features
like playing mp3 in a text processing program, then that's
true but irrelevant. In many cases people use non-standard stuff
(like directories) not because it's fascinating, but because it's
actually very basic stuff (like directories) they need in the program.

Yevgen

 

[Yevgen Muntyan]

More important is the fact that subset of programs that *are written*
in 100% ISO C is very small. Much, much smaller than of those which
*can* be written in standard C.

I doubt this is quite what you meant to say. Using the Standard
C grammar as a generative grammar, we can generate an infinite
number of "100% ISO C" programs, at least if we ignore translation
limits.[1] Clearly any finite number -- the number of actual programs
existing in the world today, whether in C or in any other language
-- is much less than infinity.

Um, I said very true thing: the number of programs which are written in
standard C (some finite number) is certainly much smaller than the
number of programs which can be written in standard C (infinity).

Yevgen

 

[santosh]

More important is the fact that subset of programs that *are written*
in 100% ISO C is very small. Much, much smaller than of those which
*can* be written in standard C.

I doubt this is quite what you meant to say. Using the Standard
C grammar as a generative grammar, we can generate an infinite
number of "100% ISO C" programs, at least if we ignore translation
limits.[1] Clearly any finite number -- the number of actual programs
existing in the world today, whether in C or in any other language
-- is much less than infinity.

Um, I said very true thing: the number of programs which are written in
standard C (some finite number) is certainly much smaller than the
number of programs which can be written in standard C (infinity).

Don't you mean to say:

"the number of programs which are written in standard C (some finite
number)
is certainly much smaller than the number of programs which can be
written in
C (infinity)."

 

[Yevgen Muntyan]

More important is the fact that subset of programs that *are written*
in 100% ISO C is very small. Much, much smaller than of those which
*can* be written in standard C.
I doubt this is quite what you meant to say. Using the Standard
C grammar as a generative grammar, we can generate an infinite
number of "100% ISO C" programs, at least if we ignore translation
limits.[1] Clearly any finite number -- the number of actual programs
existing in the world today, whether in C or in any other language
-- is much less than infinity.

Um, I said very true thing: the number of programs which are written in
standard C (some finite number) is certainly much smaller than the
number of programs which can be written in standard C (infinity).

Don't you mean to say:

"the number of programs which are written in standard C (some finite
number)
is certainly much smaller than the number of programs which can be
written in
C (infinity)."

Nope.

 

[Stephen Sprunk]

I didn't think for a single second you would. Anyway, are you saying
that many programs are actually written in standard C? What OS is
that, and what programs? If you will say that there are thousands
over the world, it most certainly will be true. But how many
programs installed on your computer or on my computer are
written in standard C? And how lucky are you if you got to write a
program where you don't need any stuff which isn't in C standard? ....
Anyway, nobody said every program needs to play music. And
lot of programs which are not written in standard C *can*
be rewritten in standard C. Everybody can implement hash tables
and regular expressions, for instance. But it'd be rather strange
if people actually restricted themselves to standard C just
for standard-C-only sake. You know, POSIX, Unix, libraries,
code reuse, coding cost and all that, aka real life matters.

I'll grant there are very, very few programs that are 100% Standard C.
However, there are a great many programs where the program's core logic is
Standard C and there is a portability layer to handle the stuff that isn't.
That portability layer is definitely not Standard C. There's even
off-the-shelf layers these days that can meet all of your needs in most
cases, and your core code can be seamlessly ported to a large number of
systems (i.e. all those the portabilitylayer supports). Porting to a
completely new system may require hacking at the portability layer, but
that's life. At least all the stuff you need to touch is in one place
instead of sprinkled throughout the core logic.

The advantage of C over most other languages is that you can write both
portable and unportable code in the same language; most other modern HLLs
make it impossible to write unportable code, though they'll allow you to
link in C libraries for that purpose. IMHO, there's a strong advantage to
being able to write both parts in one language, reducing the need for two
development teams, processes, toolchains, etc.

(And yes, I've worked on several such projects, some of which were measured
in MLOC.)

S

 

[Chris Torek]

I doubt this is quite what you meant to say. Using the Standard
C grammar as a generative grammar, we can generate an infinite
number of "100% ISO C" programs, at least if we ignore translation
limits.[1] Clearly any finite number -- the number of actual programs
existing in the world today, whether in C or in any other language
-- is much less than infinity.

Um, I said very true thing: the number of programs which are written in
standard C (some finite number) is certainly much smaller than the
number of programs which can be written in standard C (infinity).

Ah, so this *is* what you meant to say. That is a true, but
trivial and pointless, statement. One can generalize it further:
"the number of real-world things that do exist, for any practical
definition of real-world, is less than infinity." For instance,
the number of spoons in the world is much smaller than infinity.
This has about as much relevance to "Standard-vs-nonStandard" C
as your claim, then.

 

[Yevgen Muntyan]

I doubt this is quite what you meant to say. Using the Standard
C grammar as a generative grammar, we can generate an infinite
number of "100% ISO C" programs, at least if we ignore translation
limits.[1] Clearly any finite number -- the number of actual programs
existing in the world today, whether in C or in any other language
-- is much less than infinity.

Um, I said very true thing: the number of programs which are written in
standard C (some finite number) is certainly much smaller than the
number of programs which can be written in standard C (infinity).

Ah, so this *is* what you meant to say. That is a true, but
trivial and pointless, statement.

You started this stuff with infinities, I thought it was a joke.
I didn't realize I should take seriously combinatorics exercises.
Or did I miss a joke now?

One can generalize it further:
"the number of real-world things that do exist, for any practical
definition of real-world, is less than infinity." For instance,
the number of spoons in the world is much smaller than infinity.
This has about as much relevance to "Standard-vs-nonStandard" C
as your claim, then.

Yep. Just as "many programs *can* be written in standard C", the RH's
claim which was supposed to mean much in practice (emphasis mine).

Yevgen

 

[Richard Heathfield]

Yevgen Muntyan said:

Anyway, are you saying
that many programs are actually written in standard C?
Sure.

What OS is that,

Which bit of "standard C" were you struggling to understand?

and what programs?

Any that have been written in standard C.

If you will say that there are thousands over
the world, it most certainly will be true. But how many programs
installed on your computer or on my computer are written in standard
C?

I would venture to suggest that there are many more on mine than on
yours.

And how lucky are you if you got to write a program where you don't
need any stuff which isn't in C standard?

I guess I must just be luckier than most, since most of the programming
I am required to do can be done in standard C. There are, of course,
exceptions, but they are off-topic here.

Sorry, don't know what "month-end run" is.

Oh. Please excuse me; I thought you were someone else. Enjoy your
studies.

 

[Dave Vandervies]

Stan Milam said:


In situations where that's true, it's typically 1% of the code base or
less

I have numbers to back this up: One module of the system I work on at
my day job contains 2256 lines of code and header files (as reported
by wc -l), of which five are compiled differently depending on whether
it's being built for the Win32 deployment or for the *nix offline test
harness (which, while I haven't verified it anywhere else, was written
to run on any sensible hosted C implementation).

So that's 0.22% of the total live code that had to be "written to abstract
away the OS or hardware platform".

(Those six lines, for if anybody is wondering, are four lines that test
for a system pre-defined macro to identify the system and define a macro
and two lines that use the macro defined inside the test.)

The reason for my admittedly somewhat provocative reply is that there is
a perception amongst some clcers that you can't write real programs in
100% ISO C. Well, I would agree with the contention that you can't
write /all/ real programs in 100% ISO C, but the subset of programs
that you /can/ write is much, much larger than people realise.

And, of the programs that you can't, the subset of the code in each
program that can be written in ISO C is also much, much larger than many
people realize.

This is
probably at least in part because many of them have grown up in a GUI
world - if it don't have gooeys, it ain't really a program - but of
course this perception is utterly false.

And, even if true, doesn't affect my addition to your observation once
you get beyond utterly trivial programs.

(My first "useful" GUI program, which was not exactly terribly
complicated, had close to half its code copied from a 100% CLC-conforming
program that I had written and tested on a different platform, and that
I didn't have to make any changes to other than cleaning up the edges
where I'd ripped it out.)


dave

--
Dave Vandervies (e-mail address removed)

Void pointers will automatically be converted to the right type when the
assignment is made. --Simon Biber and

Or to the wrong type, as the case may be. Kaz Kylheku in CLC

 

[Richard Heathfield]

Dave Vandervies said:

And, of the programs that you can't, the subset of the code in each
program that can be written in ISO C is also much, much larger than
many people realize.

And even though I seem to have got suckered into talking about programs
rather than code, it's good to know that this was noticed and fixed.
Thank you, Dave - the cheque is in the... oh, apparently it's still in
my chequebook. Never mind, eh?