question on fgets

[subramanian100in]

Suppose fgets is used to read a line of input.
char str[1024];
fgets(str, sizeof(str), stdin);
After reading some characters on the same line, if end-of-file is
encountered, will fgets return the 'str' parameter and set EOF
indicator for the stream ? Or will it return the string argument and
set EOF indicator only on subsequent call ?

Kindly clarify

Thanks
V.Subramanian

[Ben Bacarisse]

vi******@gmail. com writes:

On Jul 27, 3:42 pm, santosh <santosh....@gm ail.comwrote:

>subramanian10. [e-mail], India wrote:

Suppose fgets is used to read a line of input.
char str[1024];
fgets(str, sizeof(str), stdin);

The parenthesis to sizeof is not required except for types.

It is also not required for "types". The parenthesis is required for
the cast.

The syntax simply says:

unary-expression:
sizeof unary-expression
sizeof ( type-name )

I.e. in the form that needs ( ) they are part of the unary-expression
and they go round a type-name. It is true that a cast-expression is:

cast-expression:
unary-expression
( type-name ) cast-expression

but that does not make the ( type-name ) in the first example a cast.

--
Ben.

[Keith Thompson]

Joe Wright <jo********@com cast.netwrites:

Ralf Damaschke wrote:

>su************* *@yahoo.com, India wrote:

>>Suppose fgets is used to read a line of input.
char str[1024];
fgets(str, sizeof(str), stdin);
After reading some characters on the same line, if end-of-file is
encountered , will fgets return the 'str' parameter and set EOF
indicator for the stream ? Or will it return the string argument and
set EOF indicator only on subsequent call ?

After you got three answers that does not address your question I
will give it a try. You already stated in the question that you are
aware that fgets() will return the str parameter (as opposed NULL).(*)
If you thereafter call feof() on this stream it should return true.
7.19.1p2 requires "an end-of-file indicator that records whether
the end of the file has been reached". And by 7.19.10.2p3 "The feof
function returns nonzero if and only if the end-of-file indicator
is set for stream."
(*) I would not expect that fgets returns non-NULL on all systems
for a text file since in text files lines are required to end with
a newline.

The fgets() function has no such requirement. If the last line of a
text stream has no terminating '\n', so be it. The line in str will be
terminated with '\0' and the eof indicator will be set but str, not
NULL is returned by fgets().

C99 7.19.2p2:

A text stream is an ordered sequence of characters composed into
_lines_, each line consisting of zero or more characters plus a
terminating new-line character. Whether the last line requires a
terminating new-line character is implementation-defined.

If an implementation does require a terminating new-line character on
the last line, and a particular file doesn't have one, then I believe
the behavior of anything that attempts to read from that file is not
defined by the standard.

On most or all systems I've used, the terminating new-line character
is not required, and the behavior of fgets in that case is well
defined.

--
Keith Thompson (The_Other_Keit h) 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"

[vippstar]

On Jul 28, 4:51 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

vipps...@gmail. com writes:

On Jul 27, 3:42 pm, santosh <santosh....@gm ail.comwrote:

The parenthesis to sizeof is not required except for types.

It is also not required for "types". The parenthesis is required for
the cast.

The syntax simply says:

unary-expression:
sizeof unary-expression
sizeof ( type-name )

I.e. in the form that needs ( ) they are part of the unary-expression
and they go round a type-name. It is true that a cast-expression is:

cast-expression:
unary-expression
( type-name ) cast-expression

but that does not make the ( type-name ) in the first example a cast.

Thanks, you are right. The syntax could be

unary-expression
sizeof unary-expression
sizeof cast-expression

But I guess the standard doesn't like such definitions.

[Chris Torek]

>On Jul 28, 4:51 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>The syntax simply says:

unary-expression:

[some parts are missing here]

> sizeof unary-expression
sizeof ( type-name )

I.e. in the form that needs ( ) they are part of the unary-expression
and they go round a type-name. It is true that a cast-expression is:

cast-expression:
unary-expression
( type-name ) cast-expression

but that does not make the ( type-name ) in the first example a cast.

In article <9e************ *************** *******@2g2000h sn.googlegroups .com>
<vi******@gmail .comwrote:

>Thanks, you are right. The syntax could be

unary-expression
sizeof unary-expression
sizeof cast-expression

This would not work right, since then we would have to write, e.g.:

size_t size_of_an_int = sizeof (int) 0;

to get the size of the "int" type. (Note that a cast-expression
that includes a cast -- i.e., that is not simply a unary-expression
to begin with -- consists of a cast *followed by* another
cast-expression, so for the recursion to terminate, the last
cast-expression must consist of a unary-expression, such as the
integer constant 0 in my example.)

>But I guess the standard doesn't like such definitions.

It would be possible to factor out the token-sequence "left
parenthesis, type-name, right-parenthesis" into a new nonterminal
such as "cast-prefix", giving:

unary-expr:
postfix-expr
++ unary-expr
-- unary-expr
unary-operator cast-expr
sizeof unary-expr
sizeof cast-prefix

cast-expr:
unary-expr
cast-prefix unary-expr

cast-prefix:
( type-name )

The "cast-prefix" nonterminal would be useful in describing the
syntax for C99's compound literals as well.

(One can also rewrite the entire thing as an operator precedence
grammar, removing the need for many interior nonterminals, but of
course that requires adding operator precedence to the grammar. :-) )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[vippstar]

In article <g6*********@ne ws5.newsguy.com >
On Jul 28, 2:55 pm, Chris Torek <nos...@torek.n etwrote:
<snip>

Thanks, quite informative.