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.
> 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.
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"
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
> 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
> 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
> 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
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)
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?
> 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
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.
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
Why even say it once?
> 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
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.
Interesting.
Is the using of google groups to post here undesirable by the
community?
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"
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"
> 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