471,123 Members | 791 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,123 software developers and data experts.

Q: Line Counting, K&R sec. 1.5.3 on OS X

Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?

BTW, when I changed 'int' to 'float' and changed '%d' to '%f' the D
stopped showing up.

Thanks!
Nov 14 '05 #1
34 1915
In article <sp*******************************@news.easynews.c om>,
Mo Geffer <sp*********@optonline.net> wrote:
Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?


That was the operating system's terminal driver echoing "^D" when you
typed Control-D; it then moved the cursor to the beginning of the line.
Then the program displayed "2", which overwrote the "^" in "^D".

--
Barry Margolin, ba****@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Nov 14 '05 #2
In article <ba**************************@comcast.dca.giganews .com>,
Barry Margolin <ba****@alum.mit.edu> wrote:
In article <sp*******************************@news.easynews.c om>,
Mo Geffer <sp*********@optonline.net> wrote:
Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?


That was the operating system's terminal driver echoing "^D" when you
typed Control-D; it then moved the cursor to the beginning of the line.
Then the program displayed "2", which overwrote the "^" in "^D".


Yikes!! Is there a way to "fix" this? Is this BSD-related (Mac OS X and
OpenBSD)?
Nov 14 '05 #3
Mo Geffer wrote:

Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?

BTW, when I changed 'int' to 'float' and changed '%d' to '%f' the D
stopped showing up.


I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

Nov 14 '05 #4
As mentioned by Barry, this problem is not actually a problem, your terminal
will echo ^D as the character for control+D. Although this behaviour is
operating system specific, it's not confined to BSD. You should probably not
attempt to fix this "problem" as that would require mutilating your termcap
or some other such nasty hack. Either way, this is off-topic. The best
solution is to add a "\n" before printing anything after receiving an EOF,
resulting in the ^D being placed on a line on its own and not interfering
with your result output. I was actually under the impression UNIX did this
for you, but it appears I'm just used to other people's code doing it. I've
learned something by lurking :)

--
~Kieran Simkin
Digital Crocus
http://digital-crocus.com/

"Mo Geffer" <sp*********@optonline.net> wrote in message
news:sp*******************************@news.easyne ws.com...
In article <ba**************************@comcast.dca.giganews .com>,
Barry Margolin <ba****@alum.mit.edu> wrote:
In article <sp*******************************@news.easynews.c om>,
Mo Geffer <sp*********@optonline.net> wrote:
Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?


That was the operating system's terminal driver echoing "^D" when you
typed Control-D; it then moved the cursor to the beginning of the line.
Then the program displayed "2", which overwrote the "^" in "^D".


Yikes!! Is there a way to "fix" this? Is this BSD-related (Mac OS X and
OpenBSD)?

Nov 14 '05 #5
On Sat, 22 May 2004, Mo Geffer wrote:
In article <ba**************************@comcast.dca.giganews .com>,
Barry Margolin <ba****@alum.mit.edu> wrote:
In article <sp*******************************@news.easynews.c om>,
Mo Geffer <sp*********@optonline.net> wrote:
Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
Just a side note about your program. If you do not specific a return type
for a function it defaults to int. It does not default to void as many
people seem to assume. This means your program assumes main() returns an
int but you have no return statement.

There are two solutions. The first is to change "main()" to "void main()".
The second is to add a "return 0;" to the end of the function. The first
will cause undefined behaviour so I always go for the second solution.

Are you using the first edition of The C Programming Language? The second
edition should say "ANSI" on the cover. The first edition does assume a
main() without an explicit return type has no return type but it pre-dates
the keyword void and the ANSI/ISO standard.
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?


That was the operating system's terminal driver echoing "^D" when you
typed Control-D; it then moved the cursor to the beginning of the line.
Then the program displayed "2", which overwrote the "^" in "^D".


Yikes!! Is there a way to "fix" this? Is this BSD-related (Mac OS X and
OpenBSD)?


You could always do something like:

printf("\n%d\n", nl);

You will still see the ^D on the terminal output but the results will
print on a seperate line.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov
Nov 14 '05 #6
In article <nozrc.1047$c94.729@newsfe4-gui>,
"Kieran Simkin" <ki****@digital-crocus.com> wrote:
As mentioned by Barry, this problem is not actually a problem, your terminal
will echo ^D as the character for control+D. Although this behaviour is
operating system specific, it's not confined to BSD. You should probably not
attempt to fix this "problem" as that would require mutilating your termcap
or some other such nasty hack. Either way, this is off-topic. The best
solution is to add a "\n" before printing anything after receiving an EOF,
resulting in the ^D being placed on a line on its own and not interfering
with your result output. I was actually under the impression UNIX did this
for you, but it appears I'm just used to other people's code doing it. I've
learned something by lurking :)

--
~Kieran Simkin
Digital Crocus
http://digital-crocus.com/

"Mo Geffer" <sp*********@optonline.net> wrote in message
news:sp*******************************@news.easyne ws.com...
In article <ba**************************@comcast.dca.giganews .com>,
Barry Margolin <ba****@alum.mit.edu> wrote:
In article <sp*******************************@news.easynews.c om>,
Mo Geffer <sp*********@optonline.net> wrote:

> Greetings:
>
> I have a question about the output of the sample program in section
> 1.5.3 Line Counting of K&R, Second Edition.


<snip>

Okay, I went with Kieran's solution. At least my output makes sense now.

Thanks all!!
Nov 14 '05 #7
In article <40***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Do you have any real reason to believe this will solve his problem, or
are you just posting to see yourself in print?

--
Barry Margolin, ba****@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Nov 14 '05 #8
Program runs fine on a linux OS
Nov 14 '05 #9
In article <Pi******************************@drj.pf>,
da*****@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) wrote:

Just a side note about your program. If you do not specific a return type
for a function it defaults to int. It does not default to void as many
people seem to assume. This means your program assumes main() returns an
int but you have no return statement.

There are two solutions. The first is to change "main()" to "void main()".
The second is to add a "return 0;" to the end of the function. The first
will cause undefined behaviour so I always go for the second solution.

Are you using the first edition of The C Programming Language? The second
edition should say "ANSI" on the cover. The first edition does assume a
main() without an explicit return type has no return type but it pre-dates
the keyword void and the ANSI/ISO standard.
I'm using the second edition.
> /****************************************/
>
> Here's my session running the program:
> /****************************************/
> G4:~/c jeff$ ./linecnt
> jeff
> tom
> 2D
> G4:~/c jeff$
> /****************************************/
>
> After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
> but what's with the 'D'??
>
> I ran the same program on both an OS X machine (gcc v. 3.3) and an
> OpenBSD 3.3 (gcc 2.95) machine and got the same results.
>
> So, again, what's the 'D' all about?

That was the operating system's terminal driver echoing "^D" when you
typed Control-D; it then moved the cursor to the beginning of the line.
Then the program displayed "2", which overwrote the "^" in "^D".


Yikes!! Is there a way to "fix" this? Is this BSD-related (Mac OS X and
OpenBSD)?


You could always do something like:

printf("\n%d\n", nl);

You will still see the ^D on the terminal output but the results will
print on a seperate line.


Yup, that's what I decided to go with.

Thanks!
Nov 14 '05 #10
Barry Margolin wrote:
CBFalconer <cb********@yahoo.com> wrote:
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Do you have any real reason to believe this will solve his problem,
or are you just posting to see yourself in print?


Since I do not have his exact system, I obviously don't know
whether that will solve his problem. Others have come up with
good explanations. However you obviously don't believe that the
code should be made conformant before looking for system
peculiarities. Let me encourage you in writing and using code
whose behavious is undefined. But please mark those efforts
clearly, so I and others can avoid them like the plague.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
Nov 14 '05 #11
In article <40***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:
Barry Margolin wrote:
CBFalconer <cb********@yahoo.com> wrote:
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Do you have any real reason to believe this will solve his problem,
or are you just posting to see yourself in print?


Since I do not have his exact system, I obviously don't know
whether that will solve his problem. Others have come up with
good explanations. However you obviously don't believe that the
code should be made conformant before looking for system
peculiarities. Let me encourage you in writing and using code
whose behavious is undefined. But please mark those efforts
clearly, so I and others can avoid them like the plague.


I certainly have nothing against code being written properly, but I
don't believe in misleading posts. Although the standard allows for
arbitrary behavior of non-conforming programs, any experienced
programmer knows what kinds of misbehaviors are actually likely in real
systems.

It's certainly a good idea to write conformant code, and if you'd said
something like "It probably won't solve the specific problem you asked
for, but you need to fix the following mistakes" I wouldn't have had any
problem. But please don't pretend that you thought that making the code
conformant would change the terminal driver's echoing of "^D".

--
Barry Margolin, ba****@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Nov 14 '05 #12
In article <vi**************************@comcast.dca.giganews .com>,
"Michael Vilain <vi****@spamcop.net>" wrote:
In article <40***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Just as a point of order, I sorta take K&R as being the equivalent of
"my grandfather's C textbook". It probably contains things in it that
are rather "old fashioned" as Falconer pointed out. Hence, most people
post about "K&R"-style C vs. ANSI C when talking about C compilers.

[I'm _not_ an evil developer, but I understand where they come from...]


So which textbook would you recommend if not K&R?
Nov 14 '05 #13
On Sat, 22 May 2004 21:13:02 +0000, Mo Geffer wrote:
In article <vi**************************@comcast.dca.giganews .com>,
"Michael Vilain <vi****@spamcop.net>" wrote:
In article <40***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:
> I think you have run into some of the few failings in K&R.
> Replace "main()" with "int main(void)", and add "return 0;" before
> the final '}'. This should avoid undefined behaviour everywhere.


Just as a point of order, I sorta take K&R as being the equivalent of
"my grandfather's C textbook". It probably contains things in it that
are rather "old fashioned" as Falconer pointed out. Hence, most people
post about "K&R"-style C vs. ANSI C when talking about C compilers.

[I'm _not_ an evil developer, but I understand where they come from...]


So which textbook would you recommend if not K&R?


The second edition of K&R, the one that focuses on ANSI C. Commonly
referred to as K&R2 around here.

Most printings of K&R2 advertise their ANSI-compliance right on the cover
in big, red letters. Plus, copies of the first edition of K&R are pretty
much confined to the private libraries of old farts and underfunded
public/college libraries. So I think it's safe to say that K&R2 has
superseded K&R in every important respect.

(Note that K&R2 was written significantly before the newest standard, C99.
Most people don't think this is a problem since most compilers don't
(fully) support C99 anyway.)

--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

Nov 14 '05 #14
Mo Geffer wrote:
"Michael Vilain <vi****@spamcop.net>" wrote:
CBFalconer <cb********@yahoo.com> wrote:
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Just as a point of order, I sorta take K&R as being the equivalent
of "my grandfather's C textbook". It probably contains things in
it that are rather "old fashioned" as Falconer pointed out. Hence,
most people post about "K&R"-style C vs. ANSI C when talking about
C compilers.

[I'm _not_ an evil developer, but I understand where they come
from...]


So which textbook would you recommend if not K&R?


I think we all recommend K & R. However, unlike some of us who
will remain nameless, they are not perfect.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

Nov 14 '05 #15
In article <pa****************************@sig.now>,
August Derleth <se*@sig.now> wrote:
The second edition of K&R, the one that focuses on ANSI C. Commonly
referred to as K&R2 around here.


From the original post:

"I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition."

--
Steven Fisher; sd******@spamcop.net
"Morituri Nolumus Mori."
Nov 14 '05 #16
On Sun, 23 May 2004 03:11:11 +0000, Steven Fisher wrote:
In article <pa****************************@sig.now>,
August Derleth <se*@sig.now> wrote:
The second edition of K&R, the one that focuses on ANSI C. Commonly
referred to as K&R2 around here.


From the original post:

"I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition."


Oh, sorry. I was only reading the post where the differences between K&R C
and ANSI-C were mentioned.

I would still recommend K&R2, BTW. ;)

--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

Nov 14 '05 #17
In article <pa****************************@sig.now>,
August Derleth <se*@sig.now> wrote:
Oh, sorry. I was only reading the post where the differences between K&R C
and ANSI-C were mentioned.


Do you have your K&R 2e in front of you? Is the program in question
still listed that way?

I don't have mine here, but I don't remember seeing that flaw. I should
have noticed... :)

--
Steven Fisher; sd******@spamcop.net
"Morituri Nolumus Mori."
Nov 14 '05 #18
Steven Fisher wrote:
August Derleth <se*@sig.now> wrote:
Oh, sorry. I was only reading the post where the differences
between K&R C and ANSI-C were mentioned.


Do you have your K&R 2e in front of you? Is the program in
question still listed that way?


Yes and yes. Not in the errata as of roughly a year ago either.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
Nov 14 '05 #19
In <Pi******************************@drj.pf> da*****@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:
On Sat, 22 May 2004, Mo Geffer wrote:
In article <ba**************************@comcast.dca.giganews .com>,
Barry Margolin <ba****@alum.mit.edu> wrote:
> In article <sp*******************************@news.easynews.c om>,
> Mo Geffer <sp*********@optonline.net> wrote:
>
> > Greetings:
> >
> > I have a question about the output of the sample program in section
> > 1.5.3 Line Counting of K&R, Second Edition.
> >
> > Here's the program:
> > /****************************************/
> > #include <stdio.h>
> >
> > /* count lines in input */
> > main()
> > {
> > int c, nl;
> >
> > nl = 0;
> > while ((c = getchar()) != EOF)
> > if (c == '\n')
> > ++nl;
> > printf("%d\n", nl);
> > }


Just a side note about your program. If you do not specific a return type
for a function it defaults to int. It does not default to void as many
people seem to assume. This means your program assumes main() returns an
int but you have no return statement.


Which is *explicitly* allowed by the C standard. So what *exactly* is
your point?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #20
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Mo Geffer wrote:

Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?

BTW, when I changed 'int' to 'float' and changed '%d' to '%f' the D
stopped showing up.
I think you have run into some of the few failings in K&R.


Huh?!?
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Please engage your brain and explain to the rest of us why the program,
in its original form, invokes undefined behaviour.

And why would you expect the 'D' to go away after these *irrelevant*
changes.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #21
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Steven Fisher wrote:
August Derleth <se*@sig.now> wrote:
Oh, sorry. I was only reading the post where the differences
between K&R C and ANSI-C were mentioned.


Do you have your K&R 2e in front of you? Is the program in
question still listed that way?


Yes and yes. Not in the errata as of roughly a year ago either.


What should be mentioned by the errata (in context) and why?

Engage your brain before replying, please.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #22
In <vi**************************@comcast.dca.giganews .com> "Michael Vilain <vi****@spamcop.net>" writes:
In article <40***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Just as a point of order, I sorta take K&R as being the equivalent of
"my grandfather's C textbook". It probably contains things in it that
are rather "old fashioned" as Falconer pointed out. Hence, most people
post about "K&R"-style C vs. ANSI C when talking about C compilers.


The OP made it perfectly clear to anyone not reading impaired that he is
using the second edition of K&R, i.e. what we usually call K&R2. This
book provides a reasonably accurate description of the language usually
and informally called ANSI C.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #23
> True, but I've had to deal with more than my fair share of
programmers that learned their C on Windoze boxen. They very often
take the attitude that since their code, which worked on Windoze,
doesn't work in an ANSI environment means that the ANSI envoironment
is broken.


I have also encountered this very attitude with MacOS programmers.
That was even worse with them: since in the earlier days of MacOS,
there was absolutely no memory protection of any sort, their code
was often filled with pointer bugs. That would never crash under
MacOS, but when ported to another platform with memory protection
(at the time, that was Windows), it would crash on a regular basis.
And guess what? In their head, of course, that was Windows' fault.

Some developers would even claim (some lame ones, I agree) that it
was impossible to develop proper software under Windows.

Nov 14 '05 #24
In <id***********************************@netnews.com cast.net> Keep it to Usenet please <id*************@hotmail.com> writes:
In article <c8***********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop)
wrote:
The OP made it perfectly clear to anyone not reading impaired that
he is using the second edition of K&R, i.e. what we usually call
K&R2. This book provides a reasonably accurate description of the
language usually and informally called ANSI C.
I'm going to get a pedantic and say you have this backwards. ANSI C
is the defined standard, so I would say "formally called ANSI C".


Nope. The standard has a very precise name, currently ISO/IEC 9899:1999
as ammended by Technical Corrigendum 1, published on 2001-09-01. "ANSI C"
is and has always been an informal name.
Also, K&R2 is "reasonably accurate", which is not the same as
equivalent.
So what? Do you suggest that people should learn C from the C standard?
So, even if gcc x.y.z on platform X is a perfect ANSI
implementation, it will differ from K&R2.
In what respect? Even if K&R2 is not equivalent to the C standard, it
needs not be in conflict with it.
Maybe things are different
in the US, or with the circle of programmers I deal with, but K&R2 is
irrelevant.
Irrelevant for whom? It might be irrelevant for the C implementors, but
it's definitely not for the people interested in learning C.
The implementation is either ANSI or it's some platform
specific variation.


It can be both at the same time, but you're not expected to understand
this.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #25
In comp.lang.c CBFalconer <cb********@yahoo.com> wrote:
Mo Geffer wrote:

Greetings:

I have a question about the output of the sample program in section
1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}
/****************************************/

Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??

I ran the same program on both an OS X machine (gcc v. 3.3) and an
OpenBSD 3.3 (gcc 2.95) machine and got the same results.

So, again, what's the 'D' all about?

BTW, when I changed 'int' to 'float' and changed '%d' to '%f' the D
stopped showing up.
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Which undefined behavior?

AFAIK, under C90, there is such a thing as implicit int. Additionally,
the lack of a return statement will result in an "undefined value"
being returned, not in "undefined behavior".

--
Alex Monjushko (mo*******@hotmail.com)
Nov 14 '05 #26
In article <40*********************@news.club-internet.fr>,
Guillaume <gr*******@NO-SPAMmail.com> wrote:
True, but I've had to deal with more than my fair share of
programmers that learned their C on Windoze boxen. They very often
take the attitude that since their code, which worked on Windoze,
doesn't work in an ANSI environment means that the ANSI envoironment
is broken.
I have also encountered this very attitude with MacOS programmers.
That was even worse with them: since in the earlier days of MacOS,
there was absolutely no memory protection of any sort, their code
was often filled with pointer bugs. That would never crash under
MacOS, but when ported to another platform with memory protection
(at the time, that was Windows), it would crash on a regular basis.
And guess what? In their head, of course, that was Windows' fault.


My experience was quite the opposite. Since there was no memory
protection whatsoever, you were _very_ careful with your code. The code
that I helped porting to Windows (about 900,000 lines of C++) did
certainly not "crash on a regular basis".

Another major application of about one million or so lines that I ported
from MacOS 9 (no memory protection) to MacOS X had two accesses to
location zero when it was started after it compiled and linked for the
first time, and that was it. No crashes because of memory violations
after that.
Some developers would even claim (some lame ones, I agree) that it
was impossible to develop proper software under Windows.


I think there is plenty of empirical proof for this.
Nov 14 '05 #27
In article <sp*******************************@news.easynews.c om>, Mo
Geffer <sp*********@optonline.net> wrote:
Here's my session running the program:
/****************************************/
G4:~/c jeff$ ./linecnt
jeff
tom
2D
G4:~/c jeff$
/****************************************/

After typing 'tom' I hit <return> then type CTRL-D. The '2' is correct
but what's with the 'D'??
When you typed CTRL-D, I'll bet the terminal echoed it as "^D", but
without moving the cursor. Then your program printed "2" on top of the
"^".
BTW, when I changed 'int' to 'float' and changed '%d' to '%f' the D
stopped showing up.


When printing it as a float, it probably printed out 2 or more digits,
which overwrote the "^D".

To confirm the theory, try changing your printf to:
printf("\n%d\n", nl);

so it will print the answer below the "^D".

-Mark
Nov 14 '05 #28
> My experience was quite the opposite.

Well, always interesting to share different experiences.
Since there was no memory
protection whatsoever, you were _very_ careful with your code. The code
that I helped porting to Windows (about 900,000 lines of C++) did
certainly not "crash on a regular basis".
Good for you, but the claim that a lack of security makes you very
careful and that this is enough to make your code bug-free is a
wild assertion to say the least. So you've never made a single
mistake in your life? Again, good for you. But allow me to be
skeptical. Maybe we don't even need seat belts after all, because
if you drive carefully, nothing wrong can happen...
Another major application of about one million or so lines that I ported
from MacOS 9 (no memory protection) to MacOS X had two accesses to
location zero when it was started after it compiled and linked for the
first time, and that was it. No crashes because of memory violations
after that.


Again, good for you. One million of lines developed under a system with
no memory protection, and not a single access violation? I need to know
what company you're working for...
Some developers would even claim (some lame ones, I agree) that it
was impossible to develop proper software under Windows.


I think there is plenty of empirical proof for this.


Oh yeah? I've been making Windows software for years without ever
finding a single inherent problem in Windows that would prevent me from
writing "proper" software. I'm not even advocating Windows in any way,
it's just a fact. In my experience, the main issues that developers
would encounter while developing for Windows were: memory protection
and multithreaded programming. Mind you, the basic core of Windows
(I mean the NT-series, of course. 9x weren't worth shit, but that's
another debate) is extremely "mainstream" preemptive multithreading.
Nothing to fret about and no particular issues either.
Nov 14 '05 #29
In article <40*********************@news.club-internet.fr>,
Guillaume <gr*******@NO-SPAMmail.com> wrote:
Again, good for you. One million of lines developed under a system with
no memory protection, and not a single access violation? I need to know
what company you're working for...


Think about it for a minute: What are the chances that an application
_that runs stable_ on a system without memory protection accesses memory
all over the place that it shouldn't touch?

I wasn't talking about development, I was talking about moving a stable,
mature application that is used in a production environment by thousands
of people to an environment with memory protection. You claimed such
applications would crash again and again, my experience was the
opposite.
Nov 14 '05 #30
Alex Monjushko wrote:
In comp.lang.c CBFalconer <cb********@yahoo.com> wrote:
Mo Geffer wrote:

I have a question about the output of the sample program in
section 1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}

.... snip ...
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.


Which undefined behavior?

AFAIK, under C90, there is such a thing as implicit int.
Additionally, the lack of a return statement will result in an
"undefined value" being returned, not in "undefined behavior".


Nobody said there WAS UB, nor that the compiler was C90. It could
have been C99. Making the minor changes ensures the source is
compliant under both standards, and simply eliminates some
possibilities. After that one can either expect the anomaly to go
away, or go looking for the cause without worrying about source
failings.

When a nut fails to fit a bolt, I normally check that I really
have the right thread to start with.

The actual problem has long since been solved, and the above had
nothing to do with it. However it does have something to do with
the methodology of solving problems.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #31
In article <40***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:
Nobody said there WAS UB, nor that the compiler was C90. It could
have been C99. Making the minor changes ensures the source is
compliant under both standards, and simply eliminates some
possibilities. After that one can either expect the anomaly to go
away, or go looking for the cause without worrying about source
failings.

When a nut fails to fit a bolt, I normally check that I really
have the right thread to start with.

The actual problem has long since been solved, and the above had
nothing to do with it. However it does have something to do with
the methodology of solving problems.


In this case, the complaint was about the behavior observed in the
operating system after calling a C program. Returning an unspecified or
undefined value from main () to the operating system might very well
change how the OS displays the programs output, so returning 0 from main
might quite possibly have fixed the problem.

Maybe the code in the operating system looks like:

call_external_program (name, arguments, &error);
if (error == 0) {
if (outputline_incomplete ()) {
clear_to_endofline ();
gotonextline ();
}
}
Nov 14 '05 #32
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Alex Monjushko wrote:
In comp.lang.c CBFalconer <cb********@yahoo.com> wrote:
Mo Geffer wrote:

I have a question about the output of the sample program in
section 1.5.3 Line Counting of K&R, Second Edition.

Here's the program:
/****************************************/
#include <stdio.h>

/* count lines in input */
main()
{
int c, nl;

nl = 0;
while ((c = getchar()) != EOF)
if (c == '\n')
++nl;
printf("%d\n", nl);
}

... snip ...
I think you have run into some of the few failings in K&R.
Replace "main()" with "int main(void)", and add "return 0;" before
the final '}'. This should avoid undefined behaviour everywhere.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Which undefined behavior?

AFAIK, under C90, there is such a thing as implicit int.
Additionally, the lack of a return statement will result in an
"undefined value" being returned, not in "undefined behavior".


Nobody said there WAS UB,


Then, what *exactly* did you mean by the underlined statement above?
nor that the compiler was C90.
This is implied. The usage of K&R or C99 compilers must be explicitly
mentioned.
It could have been C99.
Then, a diagnostic was required.
Making the minor changes ensures the source is
compliant under both standards, and simply eliminates some
possibilities.
What possibilities, apart from a diagnostic from a C99 compiler? Which
is a non-issue in context, as conforming C99 compilers have not yet been
detected in the hands of the people struggling with the first chapter of
K&R2.

OTOH, what's the point in exposing a very green newbie (the program in
question is on page 19 of K&R2) to the specifics of C99? At this moment
he has a completely different set of priorities.
After that one can either expect the anomaly to go away,
Why? None of your changes did *anything* in the direction of suppressing
it!
or go looking for the cause without worrying about source failings.
You seemed to be the only one worrying about those completely irrelevant
issues.
The actual problem has long since been solved, and the above had
nothing to do with it. However it does have something to do with
the methodology of solving problems.


Yup, it shows how NOT to try solving problems. If the program actually
invoked undefined behaviour, e.g. by not including <stdio.h>, I agree that
removing undefined behaviour was the first priority, even if it was
extremely unlikely to change anything in the program's actual behaviour.
But suggesting purely cosmetic changes (in context) is sheer idiocy...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #33
Dan Pop wrote:
CBFalconer <cb********@yahoo.com> writes:
.... snip ...
The actual problem has long since been solved, and the above had
nothing to do with it. However it does have something to do with
the methodology of solving problems.


Yup, it shows how NOT to try solving problems. If the program
actually invoked undefined behaviour, e.g. by not including
<stdio.h>, I agree that removing undefined behaviour was the first
priority, even if it was extremely unlikely to change anything in
the program's actual behaviour. But suggesting purely cosmetic
changes (in context) is sheer idiocy...


Ah, so, according to you, failure to return a valid exit status
cannot possibly affect the action of a system on program exit. In
my abysmal ignorance I fail to follow this logic. We should all
bear in mind that the Pop is infallible.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #34
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Dan Pop wrote:
CBFalconer <cb********@yahoo.com> writes:
... snip ...
The actual problem has long since been solved, and the above had
nothing to do with it. However it does have something to do with
the methodology of solving problems.


Yup, it shows how NOT to try solving problems. If the program
actually invoked undefined behaviour, e.g. by not including
<stdio.h>, I agree that removing undefined behaviour was the first
priority, even if it was extremely unlikely to change anything in
the program's actual behaviour. But suggesting purely cosmetic
changes (in context) is sheer idiocy...


Ah, so, according to you, failure to return a valid exit status
cannot possibly affect the action of a system on program exit.


According to the C standard, *any* exit status is valid and has
implementation-defined semantics.

5 Finally, control is returned to the host environment. If the
value of status is zero or EXIT_SUCCESS, an implementation-defined
^^^^^^^^^^^^^^^^^^^^^^^^^
form of the status successful termination is returned. If the
^^^^
value of status is EXIT_FAILURE, an implementation-defined form
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
of the status unsuccessful termination is returned. Otherwise
the status returned is implementation-defined. ^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The exit status is implementation-defined (regardless of the actual
value of the exit argument). I can see no indication that the exit
status is allowed to interfere with the program behaviour.
In my abysmal ignorance I fail to follow this logic. We should all
bear in mind that the Pop is infallible.


Have the minimal decency to keep the cheap shots for the times when
you are right and I am wrong.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #35

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by yawnmoth | last post: by
4 posts views Thread by Victor Engmark | last post: by
4 posts views Thread by MARK TURNER | last post: by
4 posts views Thread by aaronfude | last post: by
4 posts views Thread by Dado | last post: by
6 posts views Thread by comp.lang.php | last post: by

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.