question about older code

[MrG{DRGN}]

Hello,

I've been saving up to buy myself some C programming texts so that I might
learn, and my wife surprised me by getting something off eBay for a fairly
cheap price. Unfortunately the book is circa 1983 and I'm not sure if the
code was good then or is still good now. The title is "Learning to Program
in C" by Thomas Plum. The first program in the book is as follows.

main()
{
write(1, "hello, world\n", 13);
}

Which compiles & runs fine in my environment <OT> WinXP MSVC++ 2005 </OT>

What I've seen posted here and about is something more along the lines of;

#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}


So my questions are;

Was the first code valid and good circa 1983?
If yes then is the first code still good and valid now, or is my compiler
just supporting depreciated functions and/or non standard code?
Should I ditch this book, and keep saving for something better?

Thanks!

 

[santosh]

Hello,

I've been saving up to buy myself some C programming texts so that I might
learn, and my wife surprised me by getting something off eBay for a fairly
cheap price. Unfortunately the book is circa 1983 and I'm not sure if the
code was good then or is still good now. The title is "Learning to Program
in C" by Thomas Plum. The first program in the book is as follows.

main()
{
write(1, "hello, world\n", 13);
}

Which compiles & runs fine in my environment <OT> WinXP MSVC++ 2005 </OT>

What I've seen posted here and about is something more along the lines of;

#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}


So my questions are;

Was the first code valid and good circa 1983?
If yes then is the first code still good and valid now, or is my compiler
just supporting depreciated functions and/or non standard code?
Should I ditch this book, and keep saving for something better?

write() is not a standard C function. It's probably a UNIX/POSIX
specific function. A ca. 1983 book is totally outdated. Since then a
lot of things like function declarations, structures, etc. have either
been changed or added.

It would be vastly better to get a more recent book like "The C
Programming Language" 2nd Edition, "Algorithms in C" etc. You can even
get them via used book shops, online or otherwise.

 

[pemo]

Hello,

I've been saving up to buy myself some C programming texts so that I
might learn, and my wife surprised me by getting something off eBay
for a fairly cheap price. Unfortunately the book is circa 1983 and
I'm not sure if the code was good then or is still good now. The
title is "Learning to Program in C" by Thomas Plum. The first program
in the book is as follows.
main()
{
write(1, "hello, world\n", 13);
}

Which compiles & runs fine in my environment <OT> WinXP MSVC++ 2005
</OT>
What I've seen posted here and about is something more along the
lines of;
#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}


So my questions are;

Was the first code valid and good circa 1983?
If yes then is the first code still good and valid now, or is my
compiler just supporting depreciated functions and/or non standard
code? Should I ditch this book, and keep saving for something better?

Interesting, I copy/pasted your code into VC6 and it didn't compile. I then
copied it into VS2005 and it did ... with warnings about write() being
undeclared. However, it ran fine.

After a bit more sniffing about [grepping headers really] it looks as though
this function [int write(int, const void *, unsigned int)] is declared in
io.h - I think it's used [was used] for writing DOS applications.

 

[Herbert Rosenau]

Hello,

I've been saving up to buy myself some C programming texts so that I might
learn, and my wife surprised me by getting something off eBay for a fairly
cheap price. Unfortunately the book is circa 1983 and I'm not sure if the
code was good then or is still good now. The title is "Learning to Program
in C" by Thomas Plum. The first program in the book is as follows.

The book is deprecated since more than 15 years now.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Keith Thompson]

I've been saving up to buy myself some C programming texts so that I might
learn, and my wife surprised me by getting something off eBay for a fairly
cheap price. Unfortunately the book is circa 1983 and I'm not sure if the
code was good then or is still good now. The title is "Learning to Program
in C" by Thomas Plum. The first program in the book is as follows.

main()
{
write(1, "hello, world\n", 13);
}

Which compiles & runs fine in my environment <OT> WinXP MSVC++ 2005 </OT>

What I've seen posted here and about is something more along the lines of;

#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}


So my questions are;

Was the first code valid and good circa 1983?
If yes then is the first code still good and valid now, or is my compiler
just supporting depreciated functions and/or non standard code?
Should I ditch this book, and keep saving for something better?

There are (to oversimplify a bit) two sets of I/O functions: a set
that works with file descriptors (small integer values that represent
open files; 0 is stdin, 1 is stdout, 2 is stderr), and a set that
works with FILE* (a pointer to a structure that describes an open
file). The latter are generally considered higher-level than the
former, and are sometimes implemented on top of them.

When the C language was standardized (the ANSI standard was released
in 1989), the committee choose to standardize the FILE* functions
rather than the lower-level descriptor-based functions. The
descriptor-based functions still exist on Unix (and on other systems
that support the POSIX standard).

As of 1983, there was probably no strong reason to use one interface
or the other; I'm not even sure how old the FILE* interface is.

The code is bad in one sense, though. It uses the magic number 13,
which happens to be the length of the string "hello, world\n" -- but
since counting things is something that computers are really good at,
it's foolish to make the programmer do it manually. (Old-style
Fortran had similar problems with Hollerith strings.)

Even in old-style C, the program could have been more robust if it had
been written something like this:

main()
{
char *message = "hello, world\n";
write(1, message, strlen(message));
}

 

[MrG{DRGN}]

There are (to oversimplify a bit) two sets of I/O functions: a set
that works with file descriptors (small integer values that represent
open files; 0 is stdin, 1 is stdout, 2 is stderr), and a set that
works with FILE* (a pointer to a structure that describes an open
file). The latter are generally considered higher-level than the
former, and are sometimes implemented on top of them.

When the C language was standardized (the ANSI standard was released
in 1989), the committee choose to standardize the FILE* functions
rather than the lower-level descriptor-based functions. The
descriptor-based functions still exist on Unix (and on other systems
that support the POSIX standard).

As of 1983, there was probably no strong reason to use one interface
or the other; I'm not even sure how old the FILE* interface is.

The code is bad in one sense, though. It uses the magic number 13,
which happens to be the length of the string "hello, world\n" -- but
since counting things is something that computers are really good at,
it's foolish to make the programmer do it manually. (Old-style
Fortran had similar problems with Hollerith strings.)

Even in old-style C, the program could have been more robust if it had
been written something like this:

main()
{
char *message = "hello, world\n";
write(1, message, strlen(message));
}

Thanks for the useful replys all.

 

[Kenneth Brody]

MrG{DRGN} wrote:
[... Old "C" book from 1983 ...]

main()
{
write(1, "hello, world\n", 13);
} [...versus ...]
#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}

[...]

In addition to the other replies, I would like to point out that, back
in 1983, the memory and disk space saved by eliminating most of the
runtime library with the first version was significant.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[CBFalconer]

MrG{DRGN} wrote:

[... Old "C" book from 1983 ...]

main()
{
write(1, "hello, world\n", 13);
} [...versus ...]
#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}

[...]

In addition to the other replies, I would like to point out that,
back in 1983, the memory and disk space saved by eliminating most
of the runtime library with the first version was significant.

Still is. However the use of shared libraries (in the form of
..dlls or .so or whatever system specific mechanism) masks the
effect. In a way such things simply extend the OS to cover the
library requirements.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Kenneth Brody]

MrG{DRGN} wrote:

[... Old "C" book from 1983 ...]

main()
{
write(1, "hello, world\n", 13);
} [...versus ...]
#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}

[...]

In addition to the other replies, I would like to point out that,
back in 1983, the memory and disk space saved by eliminating most
of the runtime library with the first version was significant.

Still is. However the use of shared libraries (in the form of
.dlls or .so or whatever system specific mechanism) masks the
effect. In a way such things simply extend the OS to cover the
library requirements.

Well, the fact that they are "shared" libraries typically means that the
O/S only loads one copy into memory. Also, you will probably end up with
the entire C runtime library in memory, even if you don't use any of it.

Note that the above programs (on my Linux box) end up being only 3,060
and 3,076 bytes, respectively. A "size" shows 1,081 and 1,098.

Of course, on an old DOS box, you're probably talking about a few
hundred versus tens of thousands of bytes, which was a big thing 20
years ago. (Given the talk of TC 1.0 in the "help me atleast now",
I wonder if anyone can actaully try this out?)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[CBFalconer]

Well, the fact that they are "shared" libraries typically means
that the O/S only loads one copy into memory. Also, you will
probably end up with the entire C runtime library in memory, even
if you don't use any of it.

True, but the use of virtual memory usually means that the majority
of the unused code portion will remain swapped out. TASTAAFL.
(there are such ...)

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>