porting vs migrating

[subramanian100in]

Is there any difference between porting and migrating.

Kindly explain

[Ian Collins]

su**************@yahoo.com, India wrote:

Is there any difference between porting and migrating.

Swallows migrate, unfortunate programmers port.

--
Ian Collins.

[santosh]

su**************@yahoo.com, India wrote:

Is there any difference between porting and migrating.

Kindly explain

Kindly read your textbook.

[Flash Gordon]

su**************@yahoo.com, India wrote, On 03/03/07 06:50:

Is there any difference between porting and migrating.

Yes, porting is what porters do and migrating is what migratory birds do.

Kindly explain

Kindly explain why this is a C question.
--
Flash Gordon
Working on a Saturday due to too many work interruptions during the week.

[Flash Gordon]

Ian Collins wrote, On 03/03/07 07:22:

su**************@yahoo.com, India wrote:

>Is there any difference between porting and migrating.

Swallows migrate, unfortunate programmers port.

Some programmers drink port as well.
--
Flash Gordon

[Richard Heathfield]

su**************@yahoo.com, India said:

Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[websnarf]

On Mar 3, 3:26 am, Richard Heathfield <[e-mail]:

[e-mail], India said:

Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

Yes, unfortunately, this is a mainly theoretic view of the subject,
since there are almost no real world examples of this.

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

[Richard Heathfield]

we******@gmail.com said:

On Mar 3, 3:26 am, Richard Heathfield <[e-mail]:

>[e-mail], India said:

Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process
taking just a few seconds, if you wrote the C code properly.

Yes, unfortunately, this is a mainly theoretic view of the subject,
since there are almost no real world examples of this.

Of what? People writing C code properly?

In my universe, porting code between systems is normal, even
commonplace, and the most frequent porting issue for me is simply that
the compiler on one system picks up on some minor code flaw that the
other compiler ignored. The fix is generally a one-liner.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Beej Jorgensen]

Richard Heathfield <rj*@see.sig.invalidwrote:

>In my universe, porting code between systems is normal

Mine, too, but that was because we had a massive compatibility layer
underneath. I developed for three platforms simultaneously--the "port"
was basically a different Makefile.

But if you wanted it on a new platform, another engineer (or team of
engineers) came in and ported that compatibility layer. That was
not a one-liner.

-Beej

[Flash Gordon]

we******@gmail.com wrote, On 03/03/07 15:35:

On Mar 3, 3:26 am, Richard Heathfield <[e-mail]:

>[e-mail], India said:

>>Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

Yes, unfortunately, this is a mainly theoretic view of the subject,
since there are almost no real world examples of this.

Fortunately a major part of one of the projects I have worked on was one
such example. I was able to debug most of the embedded code on a
workstation which had better facilities than the embedded target, then I
just recompiled the same code for the embedded system and it worked.
--
Flash Gordon

[Eric Sosman]

we******@gmail.com wrote:

On Mar 3, 3:26 am, Richard Heathfield <[e-mail]:

>[e-mail], India said:

>>Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

Yes, unfortunately, this is a mainly theoretic view of the subject,
since there are almost no real world examples of this.

That was true in the Bad Old Days, before the ANSI Standard.
A typical "portable" program from that era was larded and barded
with #ifdef and other preprocessor prestidigitation to the point
of near-unreadability. Porting was a struggle.

Them days, they be gone. The single most beneficial effect
of the Standard was, in my opinion, to make the Bad Old Ways of
the Bad Old Days largely unnecessary; C is now a far more portable
language than it was in the 1980's. There is a price to be paid,
of course: One can gain the benefit of the Standard only to the
degree that one is willing to live within its strictures. Some
remain unwilling to hobble their "creativity" and "freedom;" they
have a different view of C's portability than do others, probably
because of their experiences with their own programs.

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

"su**************@yahoo.com, India" wrote:

>
Is there any difference between porting and migrating.

The elk in Northern Canada and Alaska migrate. I have never heard
of them porting. Birds migrate, but very rarely port. Ships turn
to port (or starboard), but rarely migrate.

--
Some informative links:
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)
<http://members.fortunecity.com/nnqweb/ (newusers)

[Bill Reid]

Beej Jorgensen <be**@beej.uswrote in message news:es**********@aioe.org...

Richard Heathfield <rj*@see.sig.invalidwrote:

In my universe, porting code between systems is normal

BWHAHAHAHAHAHA!!! I also like the part about
ports being a "trouble-free process taking just a few seconds,
if you wrote the C code properly"...isn't this the point where
he says, "I'm here all week, try the veal"?

Mine, too,

You live in his mother's basement too?

but that was because we had a massive compatibility layer
underneath.

Apparently not, because you just gave the correct answer for
actual real-world large-scale applications running on actual general
purpose computers...

I developed for three platforms simultaneously--the "port"
was basically a different Makefile.

Well, "basically" is the key word there, but I've seen compatibility
packages that supported like nine systems or more, without too much
drama. But, in order to to comply with the compatibility rules you had
to do a whole bunch of stuff that frequently causes group hissy-fits here...

But if you wanted it on a new platform, another engineer (or team of
engineers) came in and ported that compatibility layer. That was
not a one-liner.

Well, for mommy's basement fantasy "Hello World" programs,
it would be a zero-liner, just like Java "ports"...

---
William Ernest Reid

[Beej Jorgensen]

Bill Reid <ho********@happyhealthy.netwrote:

>You live in his mother's basement too?
Well, for mommy's basement fantasy "Hello World" programs,
it would be a zero-liner, just like Java "ports"...

Well, I was being ironic.

Are you being ironic, too?

-Beej

[Stan Milam]

Richard Heathfield wrote:

su**************@yahoo.com, India said:

>Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

I think there may be a distinction here. Yes, migrating is moving and
recompiling all that properly, standard conforming, written code.
However, porting will have to be done for all that code written to
abstract away the OS or hardware platform, and that is where the devil
lives.

--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========

[Stephen Sprunk]

<su**************@yahoo.comwrote in message
news:11*********************@31g2000cwt.googlegrou ps.com...

Is there any difference between porting and migrating.

There's no formal definitions I'm aware of, but in general when you "port"
software, you are making it so that the code works on a new system in
addition to the old one, i.e. it has to work on both. In contrast, when you
"migrate" something, having it work on the old system is not a goal, so you
may make more disruptive changes.

For instance, many companies "migrated" apps from DOS to Windows. However,
they would then "port" the Windows app to MacOS. UNIX-ish apps tend to be
ported to dozens of systems.

Depending on how well your code is written, the process of porting or
migrating may take anywhere from minutes to years. Generally the first port
is hard, since it typically means creating a platform abstraction layer
(assuming your code didn't have one from the start), and after that they're
relatively easy. Migrations seem to always be hard, but they're hopefully
infrequent.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Stan Milam said:

Richard Heathfield wrote:

>su**************@yahoo.com, India said:

>>Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process
taking just a few seconds, if you wrote the C code properly.

I think there may be a distinction here. Yes, migrating is moving and
recompiling all that properly, standard conforming, written code.
However, porting will have to be done for all that code written to
abstract away the OS or hardware platform, and that is where the devil
lives.

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. 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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[jaysome]

On Sat, 03 Mar 2007 11:26:08 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>su**************@yahoo.com, India said:

>Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

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?)
hello.c(1) : error C2018: unknown character '0x89'
hello.c(1) : error C2018: unknown character '0x95'
hello.c(1) : error C2018: unknown character '0x83'
hello.c(1) : error C2018: unknown character '0x93'
hello.c(1) : error C2018: unknown character '0xa4'
hello.c(1) : error C2018: unknown character '0x84'
hello.c(1) : error C2018: unknown character '0x85'
hello.c(1) : error C2018: unknown character '0x40'
hello.c(1) : error C2018: unknown character '0xa2'
hello.c(1) : error C2018: unknown character '0xa3'
hello.c(1) : error C2018: unknown character '0x84'
hello.c(1) : error C2018: unknown character '0x89'
hello.c(1) : error C2018: unknown character '0x96'
hello.c(1) : error C2018: unknown character '0x88'
hello.c(1) : error C2018: unknown character '0x89'
hello.c(1) : error C2018: unknown character '0x95'
hello.c(1) : error C2018: unknown character '0xa3'
hello.c(1) : error C2018: unknown character '0x40'
hello.c(1) : error C2018: unknown character '0x94'
hello.c(1) : error C2018: unknown character '0x81'
hello.c(1) : error C2018: unknown character '0x89'
hello.c(1) : error C2018: unknown character '0x95'
hello.c(1) : error C2018: unknown character '0xa5'
hello.c(1) : error C2018: unknown character '0x96'
hello.c(1) : error C2018: unknown character '0x89'
hello.c(1) : error C2018: unknown character '0x84'
hello.c(1) : error C2018: unknown character '0xc0'
hello.c(1) : error C2018: unknown character '0x5'
hello.c(1) : error C2018: unknown character '0x97'
hello.c(1) : error C2018: unknown character '0x99'
hello.c(1) : error C2018: unknown character '0x89'
hello.c(1) : error C2018: unknown character '0x95'
hello.c(1) : error C2018: unknown character '0xa3'
hello.c(1) : error C2018: unknown character '0x86'
hello.c(1) : error C2018: unknown character '0x7f'
hello.c(1) : error C2018: unknown character '0xc8'
hello.c(1) : error C2018: unknown character '0x85'
hello.c(1) : error C2018: unknown character '0x93'
hello.c(1) : error C2018: unknown character '0x93'
hello.c(1) : error C2018: unknown character '0x96'
hello.c(1) : error C2018: unknown character '0x40'
hello.c(1) : error C2018: unknown character '0xa6'
hello.c(1) : error C2018: unknown character '0x96'
hello.c(1) : error C2018: unknown character '0x99'
hello.c(1) : error C2018: unknown character '0x93'
hello.c(1) : error C2018: unknown character '0x84'
hello.c(1) : error C2018: unknown character '0xe0'
hello.c(1) : error C2018: unknown character '0x95'
hello.c(1) : error C2018: unknown character '0x7f'
hello.c(1) : error C2018: unknown character '0x5'
hello.c(1) : error C2018: unknown character '0x99'
hello.c(1) : error C2018: unknown character '0x85'
hello.c(1) : error C2018: unknown character '0xa3'
hello.c(1) : error C2018: unknown character '0xa4'
hello.c(1) : error C2018: unknown character '0x99'
hello.c(1) : error C2018: unknown character '0x95'
hello.c(1) : error C2018: unknown character '0x40'
hello.c(1) : error C2018: unknown character '0xf0'
hello.c(1) : error C2018: unknown character '0xd0'
hello.c(2) : fatal error C1004: unexpected end of file found
Error executing cl.exe.
hello.exe - 62 error(s), 0 warning(s)

I also compiled it with gcc and got an error:

gcc -Wall -W -o hello hello.c
main.c:1: parse error before `{'

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.

Best regards
--
jay

[santosh]

jaysome wrote:

On Sat, 03 Mar 2007 11:26:08 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

su**************@yahoo.com, India said:

Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

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?)
hello.c(1) : error C2018: unknown character '0x89'

<snip>

hello.c(2) : fatal error C1004: unexpected end of file found
Error executing cl.exe.
hello.exe - 62 error(s), 0 warning(s)

I also compiled it with gcc and got an error:

gcc -Wall -W -o hello hello.c
main.c:1: parse error before `{'

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.

But, this can be called porting or migrating, since it involves no
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.

[santosh]

santosh wrote:

jaysome wrote:

On Sat, 03 Mar 2007 11:26:08 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>su**************@yahoo.com, India said:
>
>Is there any difference between porting and migrating.
>
>Not as far as C is concerned. They both mean "copy the source code to
>the new system, and re-compile". This is a trouble-free process taking
>just a few seconds, if you wrote the C code properly.

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?)
hello.c(1) : error C2018: unknown character '0x89'

<snip>

hello.c(2) : fatal error C1004: unexpected end of file found
Error executing cl.exe.
hello.exe - 62 error(s), 0 warning(s)

I also compiled it with gcc and got an error:

gcc -Wall -W -o hello hello.c
main.c:1: parse error before `{'

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.

But, this can be called porting or migrating, [ ... ]

Sorry, I meant to write:

But this can't be called porting or migrating, [ ... ]

Why do typos tend to strike in the worst possible space?

[Flash Gordon]

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

On Sat, 03 Mar 2007 11:26:08 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>su**************@yahoo.com, India said:

>>Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process taking
just a few seconds, if you wrote the C code properly.

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?)

<snip>

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

[Flash Gordon]

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

jaysome wrote:

<snip>

>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.

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.
--
Flash Gordon

[Yevgen Muntyan]

Richard Heathfield wrote:

Stan Milam said:

>Richard Heathfield wrote:

>>su**************@yahoo.com, India said:

Is there any difference between porting and migrating.
Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process
taking just a few seconds, if you wrote the C code properly.

I think there may be a distinction here. Yes, migrating is moving and
recompiling all that properly, standard conforming, written code.
However, porting will have to be done for all that code written to
abstract away the OS or hardware platform, and that is where the devil
lives.

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:

<snip>

>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.

I am not convinced by your claim.

>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.

*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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Torek]

In article <nDDGh.554$3i.499@trnddc01>
Yevgen Muntyan <mu****************@tamu.eduwrote:

>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.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Yevgen Muntyan]

Richard Heathfield wrote:

Yevgen Muntyan said:

>Richard Heathfield wrote:

<snip>

>>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.

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?

>>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.

*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]

Chris Torek wrote:

In article <nDDGh.554$3i.499@trnddc01>
Yevgen Muntyan <mu****************@tamu.eduwrote:

>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]

Yevgen Muntyan wrote:

Chris Torek wrote:

In article <nDDGh.554$3i.499@trnddc01>
Yevgen Muntyan <mu****************@tamu.eduwrote:

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]

santosh wrote:

Yevgen Muntyan wrote:

>Chris Torek wrote:

>>In article <nDDGh.554$3i.499@trnddc01>
Yevgen Muntyan <mu****************@tamu.eduwrote:
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]

"Yevgen Muntyan" <mu****************@tamu.eduwrote in message
news:DbJGh.921$NA4.687@trnddc07...

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

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

--
Posted via a free Usenet account from http://www.teranews.com

[Chris Torek]

>In article <nDDGh.554$3i.499@trnddc01>

>Yevgen Muntyan <mu****************@tamu.eduwrote:

>>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.

>Chris Torek wrote:

>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.

In article <djJGh.923$NA4.229@trnddc07>,
Yevgen Muntyan <mu****************@tamu.eduwrote:

>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. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Yevgen Muntyan]

Chris Torek wrote:

>>In article <nDDGh.554$3i.499@trnddc01>
Yevgen Muntyan <mu****************@tamu.eduwrote:
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.

>Chris Torek wrote:

>>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.

In article <djJGh.923$NA4.229@trnddc07>,
Yevgen Muntyan <mu****************@tamu.eduwrote:

>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.

<snip>

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

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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Dave Vandervies]

In article <iL******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>Stan Milam said:

>Richard Heathfield wrote:

>>su**************@yahoo.com, India said:

Is there any difference between porting and migrating.

Not as far as C is concerned. They both mean "copy the source code to
the new system, and re-compile". This is a trouble-free process
taking just a few seconds, if you wrote the C code properly.

I think there may be a distinction here. Yes, migrating is moving and
recompiling all that properly, standard conforming, written code.
However, porting will have to be done for all that code written to
abstract away the OS or hardware platform, and that is where the devil
lives.

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 dj******@csclub.uwaterloo.ca

>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:

In article <iL******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

>>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.

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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.