Date: Tue, 11 Apr 2000 13:44:43 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: djgpp-workers AT delorie DOT com
Subject: Ansi/iso C compliance whatever it may eventually mean (fwd)
Message-ID: <Pine.SUN.3.91.1000411134249.4929S-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com

Regarding the below: should filbuf.c leave the ^Z character alone when 
the stream is connected to the console?  (If this doesn't make sense, 
look at src/libc/ansi/stdio/filbuf.c in djlsr203.zip.)

---------- Forwarded message ----------
Date: Tue, 11 Apr 2000 06:31:50 +0530
From: Bharat Mallapur <bharatmallapur AT eth DOT net>
To: djgpp AT delorie DOT com
Subject: Ansi/iso C compliance whatever it may eventually mean

I got the following response e-mail from gnu-bugs AT gcc DOT gnu DOT org

in short i want to know that how is it that gcc which is supposed to be
"totally" ansi/iso compliant not have getchar which is a standard library
function.The use of getchar in K&R 2 and in many ansi compliant programs
seems to be enough to call it ansi-compliant.
The fact is i decided to download djgpp only after being told on comp.lang.c
that it is a fully ansi/iso compliant compiler and of course that it is
free.
 So now please tell me whether djgpp is ansi/iso C compliant or not.

e-mail me at :
guruduttmallapur AT usa DOT net or bharatmallapur AT eth DOT net

The following is what transpired :
> From: "Bharat Mallapur" <bharatmallapur AT eth DOT net>
> To: <gcc-bugs AT gcc DOT gnu DOT org>
> Cc: <bug-gcc AT gnu DOT org>

>Please only send in bugs to one address, not two.

> Date: Mon, 10 Apr 2000 21:11:18 +0530
> Bug report for gcc

>This is not a bug in gcc.  gcc doesn't provide getchar.  You can try
>submitting a bug report to djgpp.  Also, you may want a book on UNIX
>programming.  There is a lot of detail here that I think influences
>this, but that you may not know about.  See raw tty mode v nonraw tty
>mode and the precise semantics of the EOF character, and what it >means
>and where it means it.

>The C FAQ might cover some of the details, see comp.lang.c.

>>Bug report for gcc version 2.95.2 19991024 (release)
>>contact me by e-mail at : guruduttmallapur AT usa DOT net

>>I am running MS-DOS (Windows 98 04-10-1998 release)
>>Celeron 366 MHz.
>>RAM 64 MB

>>The gcc that i am using was recently downloaded as part of the >>djgpp set
of
>>zip files.

>>My problem is the following:
>>============================
>>/*
>> Problem : Non leading EOF is ignored by getchar().
>> Triggering :
>>             Try TYPING IN the 3 following lines when running the
program:
>>             "a ^Z the" enter/return
>>             " ^Z the"  enter/return
>>             "^Z the"   enter/return
>>             (here ^Z gives EOF and is same as Ctrl+Z)

>> My apologies if this is a wild goose chase.
>> And thanks for making gcc free.Its very essential/useful for students
>> like me.
>>*/

>>#include <stdio.h>

>>int main(void)
>>{
>> int ch=0;

>> while (1) {
>>    if ( (ch=getchar()) == EOF ) {
>>        printf("EOF in input value=%d and ch=%c", ch,ch);
>>        break;
>>    }
>>    else {
>>        printf("%c",ch);
>>    }
>> }
>> return 0;
>>}
>>/*
>> Read on :

>> The problem seems to be with getchar() dealing with EOF in >>'interactive
>>mode'
>> It works well when piping input from a text file and that too because
>>the
>>EOF
>> has already been correctly dealt with by the editor used to create the
>>file.

>> On typing the 3 following lines when running the program:
>> "a ^Z the" enter/return
>> " ^Z the"  enter/return
>> "^Z the"   enter/return

>> 1) a leading EOF causes getchar() to behave properly
>> 2) a non leading EOF causes getchar() to
>>    a) stop inputting characters
>>    b) ignore the EOF as seen by the non-triggering of the if-else

>> You may say its not a big deal but then if I were to write the above
>> program it would loop infinitely unless I entered a leading EOF.
>> Also this very same program drew my attention to the problem.

>> The fact is, it is based on an exercise program in
>> Kernighan and Ritchie second edition C prog. lang.

>> There is no problem in this program as getchar is not called again
>> and again as in a loop to input a string.

>> #include <stdio.h>

>> int main(void)
>> {
>>  int ch=0;

>>  if ( (ch=getchar()) == EOF ) {
>>     printf("EOF in input value=%d and ch=%c", ch,ch);
>>  }
>>  else {
>>      printf("%c",ch);
>>  }
>>  return 0;
>> }

>>*/