[comp.std.c] Is this a bug in Quick C?

s64421@zeus.usq.EDU.AU (house ron) (03/11/91)

A friend has found that the following program behaves oddly under
Quick C:


main()
{
    int i,j;char c;
    i = scanf("%d%c",&j,&c);
    printf("%d %d %c\n",i,j,c);
}

The idea is to have the newline typed after the number put into c.
However, Quick C version 2.5 requires that the user type TWO newlines
before any output is produced.  Earlier versions, and other C compilers
I have tried (Power C, TopSpeed C) produce their output after the
expected one newline.  I know the behaviour of Quick C V2.5 is wierd,
but is it actually ILLEGAL, according to the ANSI C standard?  It is
a question of timing, and most language standards are very lax about
that issue.

--
Regards,

Ron House.   (s64421@zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)

gwyn@smoke.brl.mil (Doug Gwyn) (03/12/91)

In article <s64421.668684042@zeus> s64421@zeus.usq.EDU.AU (house ron) writes:
>A friend has found that the following program behaves oddly under
>Quick C:
>main()
>{
>    int i,j;char c;
>    i = scanf("%d%c",&j,&c);
>    printf("%d %d %c\n",i,j,c);
>}

It's a miracle that it works at all, in the absence of a prototype for
the variadic functions scanf() and printf().  <stdio.h> should be #included
and the main() function should return a value.

>The idea is to have the newline typed after the number put into c.
>However, Quick C version 2.5 requires that the user type TWO newlines
>before any output is produced.

Assuming that that behavior persists after you change the program to be
strictly conforming to the C standard, it would be an error in the
Quick C implementation, rendering it not standard conforming.

>It is a question of timing, and most language standards are very lax about
>that issue.

It is not at all a matter of timing.

thorinn@diku.dk (Lars Henrik Mathiesen) (03/30/91)

Doug Gwyn (gwyn@smoke.brl.mil) writes:
>In article <s64421.668684042@zeus> s64421@zeus.usq.EDU.AU (house ron) writes:

>>The idea is to have the newline typed after the number put into c.
>>However, Quick C version 2.5 requires that the user type TWO newlines
>>before any output is produced.

>Assuming that that behavior persists after you change the program to be
>strictly conforming to the C standard, it would be an error in the
>Quick C implementation, rendering it not standard conforming.

I assume you refer to the discussion in section 7.9.3 (Library,
Input/Output <stdio.h>, Files). If stdin is interactive, it cannot be
fully buffered in a conforming implementation. There is some wording
about how characters "are intended to" be transmitted to and from the
host environment under the various buffering schemes, but that part
seems to be very careful not to promise anything.

If the Standard was intended to bind conforming implementations on the
exact behaviour of line buffered input from terminals, it should come
out and say so.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk

gwyn@smoke.brl.mil (Doug Gwyn) (03/30/91)

In article <1991Mar29.220525.3927@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>I assume you refer to the discussion in section 7.9.3

I know about that; I helped come up with the wording for it.
I interpreted the original posting as saying that Quick C was
consuming an extra newline.  That is NOT expected behavior,
even if one could get around it by announcing that as part of
"the way that terminals interpret newlines" in the implementation.