Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

getch() Problem?

7 views
Skip to first unread message

MicroHimalaya

unread,
Sep 8, 2009, 5:43:53 PM9/8/09
to
while((ch=getch())!='\r'&&i<MaxLen)
InStr[i++]=ch;
//InStr[i]=0;
printf("%s",InStr);


while((ch=getch())!='\n'&&i<MaxLen)
InStr[i++]=ch;
//InStr[i]=0;
printf("%s",InStr);

the first is chaos,the second is right;
the two program is different,why? explain in datil.
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Hans-Bernhard Bröker

unread,
Sep 9, 2009, 5:27:43 PM9/9/09
to
MicroHimalaya wrote:

> the two program is different,why?

Well, you have two different programs, so why are you surprised they
behave differently?

> explain in datil.

Your homework. You do it.

Keith Thompson

unread,
Sep 9, 2009, 5:28:08 PM9/9/09
to
MicroHimalaya <ykp.de...@yahoo.com.cn> writes:
> while((ch=getch())!='\r'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
>
> while((ch=getch())!='\n'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
> the first is chaos,the second is right;
> the two program is different,why? explain in datil.

getch() is not a standard C function. I'm familiar with at least two
different system-specific functions of that name (one is provided by
DOS and Windows, the other is part of curses).

Try asking in a newsgroup that deals with your system. And when you
do, I suggest providing more information about the failure than "the
first is chaos"; describe what it does and how that differs from what
you expected it to do.

[cc'ed to poster due to the slow latency of this newsgroup]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Dag-Erling Smørgrav

unread,
Sep 9, 2009, 5:28:20 PM9/9/09
to
MicroHimalaya <ykp.de...@yahoo.com.cn> writes:
> the first is chaos,the second is right;
> the two program is different,why? explain in datil.

Sounds awfully like homework, but...

Most Unix-like systems use '\n' as a line terminator. Many other
systems, and Internet protocols, use '\r\n'. Apple systems used to use
'\r', but Mac OS X (with its Unix heritage) uses '\n'.

DES
--
Dag-Erling Smørgrav - d...@des.no

Eric

unread,
Sep 9, 2009, 5:28:39 PM9/9/09
to
MicroHimalaya wrote:

> while((ch=getch())!='\r'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
>
> while((ch=getch())!='\n'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
> the first is chaos,the second is right;
> the two program is different,why? explain in datil.

Why not compile and run each one and see for yourself?
sounds like homework to me. . .
Eric

--
Msg to ET:
If you get here and there's no planet -
dont ever build a Large Hadron Collider

jyoti

unread,
Sep 9, 2009, 5:28:48 PM9/9/09
to
On Wed, 09 Sep 2009 03:13:53 +0530, MicroHimalaya
<ykp.de...@yahoo.com.cn> wrote:

> while((ch=getch())!='\r'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
>
> while((ch=getch())!='\n'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
> the first is chaos,the second is right;
> the two program is different,why? explain in datil.

They are different because '\r' is different from '\n'. Carriage return
and newline. Or is there some other catch? You can write small test
programs to find out the difference for yourself.

Regards,
Jyoti

Jens Schmidt

unread,
Sep 9, 2009, 5:29:59 PM9/9/09
to
MicroHimalaya wrote:

> while((ch=getch())!='\r'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
>
> while((ch=getch())!='\n'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
> the first is chaos,the second is right;

Level 1:
This won't compile.

Level 2:
If appropriate prefixes and suffixes are added

Prefix:

#include <stdio.h>
#define MaxLen 100
int main()
{
unsigned i = 0;
char ch;
char InStr [MaxLen];

Suffix:

return 0;
}

then the loop doen't terminate if EOF is encountered.

Level 3:
Function printf accesses unitialized space in InStr,
if i == MaxLen. This can be repaired by un-commenting
the assignment of 0 at the ends of the strings.

Level 4:
The assignments may write beyond the ends of InStr.
Change the declaration to
char InStr [MaxLen + 1];

> the two program is different,why? explain in datil.

Level 5:
### Error. Maximum explanation level for Usenet reached.
### Buy support for answers to homework questions. :-)
--
Greetings,
Jens Schmidt

tohava

unread,
Sep 9, 2009, 5:29:47 PM9/9/09
to
Because when you press return, it is translated as '\n' and not as
'\r'.
Note, getch is not standard and should not be used.

On Sep 8, 11:43 pm, MicroHimalaya <ykp.deepb...@yahoo.com.cn> wrote:
> while((ch=getch())!='\r'&&i<MaxLen)

> while((ch=getch())!='\n'&&i<MaxLen)

James Kuyper

unread,
Sep 9, 2009, 5:29:51 PM9/9/09
to
MicroHimalaya wrote:
> while((ch=getch())!='\r'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
>
> while((ch=getch())!='\n'&&i<MaxLen)
> InStr[i++]=ch;
> //InStr[i]=0;
> printf("%s",InStr);
>
> the first is chaos,the second is right;

The two pieces of code serve very different purposes; one reads in data
until it reads a carriage return, the second reads in data until it
reads a newline character.

Neither one of them checks for the possibility of an I/O error - which
by my standards is a pretty serious defect.

Neither one checks for the possibility that a null character is read in;
depending upon what you know about the input to your program, that might
be entirely appropriate, or a serious error. However, if it doesn't read
in a null character, the call to printf() could have undefined behavior,
because for some reason you commented out the lines which ensure that
the string was null terminated.

Both versions ignore the final character read when the buffer fills up,
which might or might not be a defect, depending upon what the
significance of overflowing that buffer is, and what the rest of your
program does with ch.

Ignoring those defects, either version could be "right" depending upon
what it is that it is supposed to do. What is it supposed to do?

Mark L Pappin

unread,
Sep 9, 2009, 10:31:25 PM9/9/09
to
"=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=" <d...@des.no> writes:

> Most Unix-like systems use '\n' as a line terminator. Many other
> systems, and Internet protocols, use '\r\n'. Apple systems used to use
> '\r', but Mac OS X (with its Unix heritage) uses '\n'.

If I recall correctly, as far as the C abstract machine is concerned,
ALL systems use '\n' as a line terminator, regardless of the specific
octet values (or absence of octet values, in record-structured files
for example) used by the underlying system.

mlp

Gordon Burditt

unread,
Sep 10, 2009, 1:36:45 AM9/10/09
to
>> Most Unix-like systems use '\n' as a line terminator. Many other
>> systems, and Internet protocols, use '\r\n'. Apple systems used to use
>> '\r', but Mac OS X (with its Unix heritage) uses '\n'.
>
>If I recall correctly, as far as the C abstract machine is concerned,
>ALL systems use '\n' as a line terminator, regardless of the specific
>octet values (or absence of octet values, in record-structured files
>for example) used by the underlying system.

That's true if you're reading files *in text mode*, or a console in
the normal C terminal operation. It doesn't apply to reading files
in binary mode or consoles in UNIX tty raw mode.

Mark L Pappin

unread,
Sep 10, 2009, 4:48:21 PM9/10/09
to
I'll say this once: if you quote my words, keep my name attached to
them. Permission to quote without attribution is denied to all.

gordon...@burditt.org (Gordon Burditt) writes:

(quoting me quoting somebody, both attributions removed by Gordon)

>>> Most Unix-like systems use '\n' as a line terminator. Many other
>>> systems, and Internet protocols, use '\r\n'. Apple systems used
>>> to use '\r', but Mac OS X (with its Unix heritage) uses '\n'.
>>
>> If I recall correctly, as far as the C abstract machine is
>> concerned, ALL systems use '\n' as a line terminator, regardless of
>> the specific octet values (or absence of octet values, in
>> record-structured files for example) used by the underlying system.
>
> That's true if you're reading files *in text mode*, or a console in
> the normal C terminal operation. It doesn't apply to reading files
> in binary mode or consoles in UNIX tty raw mode.

Unless you're reading files in text mode, "line" is not a concept that
applies to the data therefrom.

mlp

Ted DeLoggio

unread,
Sep 11, 2009, 12:26:13 AM9/11/09
to
On Sep 10, 4:48 pm, Mark L Pappin <m...@acm.org> wrote:
> I'll say this once: if you quote my words, keep my name attached to
> them.  Permission to quote without attribution is denied to all.
>

Why even say it once?

Mark L Pappin

unread,
Sep 11, 2009, 3:23:58 AM9/11/09
to
Ted DeLoggio <tdel...@gmail.com> writes:

> On Sep 10, 4:48 pm, Mark L Pappin <m...@acm.org> wrote:
>> I'll say this once: if you quote my words, keep my name attached to
>> them.  Permission to quote without attribution is denied to all.
>
> Why even say it once?

So Gordon doesn't quote me without attribution a second time.

He claims there's some risk, if he includes attributions, of someone
complaining of misrepresentation or some such. His removal of
attributions, however, generates many more complaints.

It's possible that quoting without attribution could be considered a
violation of the copyright in the quoted article. An article has of
course implied by being posted to Usenet that permission to quote
_with_ attribution is given. Google's munging of email addresses in
attributions (as for instance in your quote of my article) is
borderline.

mlp

James Kuyper

unread,
Sep 11, 2009, 10:18:23 AM9/11/09
to
Ted DeLoggio wrote:
> On Sep 10, 4:48�pm, Mark L Pappin <m...@acm.org> wrote:
>> I'll say this once: if you quote my words, keep my name attached to
>> them. �Permission to quote without attribution is denied to all.
>>
>
> Why even say it once?

Because Gordon Burditt has objections to including proper attributions
for words written by others that he quotes in his own messages. Those
objections make no sense to me, so I'm not sure I can do them justice.
They seem to be based upon the mistaken assumption that he is thereby
avoiding potential legal problems that might result from accidentally
misattributing the text, that are more serious than the ones he would
face for failing to properly attribute it.

Notices such as the one written by Mark Pappin are intended to put
Gordon (and incidentally, anyone else who feels the same way) on notice
that failing to include proper attributions is unacceptable to the
person posting the notice.

It would be perfectly feasible for Gordon to honor both his own
principles, and such notices, by not quoting any text written by those
who include such notices. I've never bothered to check whether he
actually does so.

Ted DeLoggio

unread,
Sep 11, 2009, 11:11:23 AM9/11/09
to
On Sep 11, 3:23 am, Mark L Pappin <m...@acm.org> wrote:
> So Gordon doesn't quote me without attribution a second time.
>
> He claims there's some risk, if he includes attributions, of someone
> complaining of misrepresentation or some such.  His removal of
> attributions, however, generates many more complaints.
>
> It's possible that quoting without attribution could be considered a
> violation of the copyright in the quoted article.  An article has of
> course implied by being posted to Usenet that permission to quote
> _with_ attribution is given.  Google's munging of email addresses in
> attributions (as for instance in your quote of my article) is
> borderline.

Interesting.

Is the using of google groups to post here undesirable by the
community?

Keith Thompson

unread,
Sep 11, 2009, 11:11:32 AM9/11/09
to
James Kuyper <james...@verizon.net> writes:
[...]

> It would be perfectly feasible for Gordon to honor both his own
> principles, and such notices, by not quoting any text written by those
> who include such notices. I've never bothered to check whether he
> actually does so.

I don't believe he's quoted anything I've written since I started
posting similar notices.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

unread,
Sep 11, 2009, 5:36:52 PM9/11/09
to
Ted DeLoggio <tdel...@gmail.com> writes:
> On Sep 11, 3:23 am, Mark L Pappin <m...@acm.org> wrote:
>> So Gordon doesn't quote me without attribution a second time.
>>
>> He claims there's some risk, if he includes attributions, of someone
>> complaining of misrepresentation or some such.  His removal of
>> attributions, however, generates many more complaints.
>>
>> It's possible that quoting without attribution could be considered a
>> violation of the copyright in the quoted article.  An article has of
>> course implied by being posted to Usenet that permission to quote
>> _with_ attribution is given.  Google's munging of email addresses in
>> attributions (as for instance in your quote of my article) is
>> borderline.
>
> Interesting.
>
> Is the using of google groups to post here undesirable by the
> community?

Not generally, no. Some people have chosen to killfile (filter out)
postings made through Google Groups because of the relatively high
proportion of spam, and you might consider finding a real newsreader
and a real news server, but most people have no problem with users of
Google Group -- as long as they use it properly.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Mark L Pappin

unread,
Sep 12, 2009, 3:06:13 AM9/12/09
to
Ted DeLoggio <tdel...@gmail.com> writes:

> On Sep 11, 3:23 am, Mark L Pappin <m...@acm.org> wrote:

>> It's possible that quoting without attribution could be considered a

>> violation of the copyright in the quoted article.  [...]


>> Google's munging of email addresses in attributions (as for
>> instance in your quote of my article) is borderline.
>
> Interesting.

To expand on my comment: while Google left my name, it mangled the
email address that I had attached to that name thus removing the
guaranteed unambiguous identification of me as author - conceptually
the same thing Gordon does, though not as severe.

mlp

0 new messages