Problem with scanf()/gets()

[subratasinha2006]

I can not accept a string (without space) of length more than 127
whatever I do..

Entry is restricted by 127 characters.

I have declared an array of size more than 200.
or
I have used dynamic memory allocation.

But the echo is stopped

[Mark Bluemel]

su**************@yahoo.co.in wrote:

I can not accept a string (without space) of length more than 127
whatever I do..

Entry is restricted by 127 characters.

I have declared an array of size more than 200.
or
I have used dynamic memory allocation.

But the echo is stopped

Sounds like a limit in the input buffer size provided by your operating
system, not a C language/library issue.

[Richard Heathfield]

Mark Bluemel said:

su**************@yahoo.co.in wrote:

>I can not accept a string (without space) of length more than 127
whatever I do..

Entry is restricted by 127 characters.

I have declared an array of size more than 200.
or
I have used dynamic memory allocation.

But the echo is stopped

Sounds like a limit in the input buffer size provided by your operating
system, not a C language/library issue.

If that's allowed by the Standard, what is the minimum such maximum input
buffer size? If none is stated, it effectively means that even hosted
implementations effectively don't have to provide stdin, since they can
simply set the input buffer size to 0, rendering it impossible to read
anything in!

In other words, I think you're wrong - if the implementation is truly
behaving as described, it sounds non-conforming to me. But I will
cheerfully point out that I'm not sure of my ground.

It's at times like this that I'm tempted to shout "CHRISSSSS!!!"

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Walter Roberson]

In article <1t******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>If that's allowed by the Standard, what is the minimum such maximum input
buffer size? If none is stated, it effectively means that even hosted
implementations effectively don't have to provide stdin, since they can
simply set the input buffer size to 0, rendering it impossible to read
anything in!

That would be contrary to the requirement to allow at least one
character of ungetc pushback.
--
"Any sufficiently advanced bug is indistinguishable from a feature."
-- Rich Kulawiec

[fred.l.kleinschmidt]

On Jan 3, 6:24*am, [e-mail] wrote:

I can not accept a string (without space) of length more than *127
whatever I do..

Entry is restricted by 127 characters.

I have declared an array of size more than 200.
or
I have used dynamic memory allocation.

But the echo is stopped

Without showing us the code, there is no way we can find the problem.
--
Fred Kleinschmidt

[Richard Heathfield]

Walter Roberson said:

In article <1t******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>If that's allowed by the Standard, what is the minimum such maximum input
buffer size? If none is stated, it effectively means that even hosted
implementations effectively don't have to provide stdin, since they can
simply set the input buffer size to 0, rendering it impossible to read
anything in!

That would be contrary to the requirement to allow at least one
character of ungetc pushback.

No, it wouldn't, because of the "as if" rule - you'd never be able to tell
that it hadn't been pushed back! :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Tobin]

In article <2c**********************************@i29g2000prf. googlegroups.com>,
<su**************@yahoo.co.inwrote:

>I can not accept a string (without space) of length more than 127
whatever I do..

Entry is restricted by 127 characters.

Do you mean input from a terminal? That may be limited by your
operating system.

-- Richard
--
:wq

[CBFalconer]

Richard Heathfield wrote:

Mark Bluemel said:

>su**************@yahoo.co.in wrote:

>>I can not accept a string (without space) of length more than
127 whatever I do..

Entry is restricted by 127 characters.

I have declared an array of size more than 200.
or
I have used dynamic memory allocation.

But the echo is stopped

Sounds like a limit in the input buffer size provided by your
operating system, not a C language/library issue.

If that's allowed by the Standard, what is the minimum such
maximum input buffer size? If none is stated, it effectively
means that even hosted implementations effectively don't have
to provide stdin, since they can simply set the input buffer
size to 0, rendering it impossible to read anything in!

Where does it say that stdin has to be editable on input?

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Walter Roberson]

In article <pe*********************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>Walter Roberson said:

>In article <1t******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>If that's allowed by the Standard, what is the minimum such maximum input
buffer size? If none is stated, it effectively means that even hosted
implementations effectively don't have to provide stdin, since they can
simply set the input buffer size to 0, rendering it impossible to read
anything in!

>That would be contrary to the requirement to allow at least one
character of ungetc pushback.

>No, it wouldn't, because of the "as if" rule - you'd never be able to tell
that it hadn't been pushed back! :-)

You are allowed to ungetc() a character that has not actually
been read, and when you read from that stream you must get that
character. Therefore stdin must be provided, even if the
functionality is only the equivilent of having stdin connected
to /dev/null
--
"There are some ideas so wrong that only a very intelligent person
could believe in them." -- George Orwell

[mrdarrett]

On Jan 3, 6:24 am, [e-mail] wrote:

I can not accept a string (without space) of length more than 127
whatever I do..

Entry is restricted by 127 characters.

I have declared an array of size more than 200.
or
I have used dynamic memory allocation.

But the echo is stopped

what OS, what compiler?

[Walter Roberson]

In article <fl***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:

>In article <2c**********************************@i29g2000prf. googlegroups.com>,
<su**************@yahoo.co.inwrote:

>>I can not accept a string (without space) of length more than 127
whatever I do..

>>Entry is restricted by 127 characters.

>Do you mean input from a terminal? That may be limited by your
operating system.

However,

C89 4.9.2 Streams
[...]

Environmental Limits

An implementation shall support text files with lines
containing at least 254 characters, including the terminating
new-line character. The value of the macro BUFSIZ shall be
at least 256.
As stdin is a stream and there is no exemption for stdin in the
above, an implementation that does not support lines of at least
254 characters on stdin is non-conformant.
--
"I was very young in those days, but I was also rather dim."
-- Christopher Priest

[Walter Roberson]

In article <1t******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>Mark Bluemel said:

>Sounds like a limit in the input buffer size provided by your operating
system, not a C language/library issue.

>If that's allowed by the Standard, what is the minimum such maximum input
buffer size? If none is stated, it effectively means that even hosted
implementations effectively don't have to provide stdin, since they can
simply set the input buffer size to 0, rendering it impossible to read
anything in!

C89 4.9.2 "Streams", Environmental Limits, indicates 254 minimum
for text streams (including newline.)
--
We regret to announce that sub-millibarn resolution bio-hyperdimensional
plasmatic space polyimaging has been delayed until the release
of Windows Vista SP2.

[Chris Dollin]

Richard Heathfield wrote:

It's at times like this that I'm tempted to shout "CHRISSSSS!!!"

C has no namespaces, so that's an ambiguous reference. Also note
what Pterry has to say about multiple exclamation marks ...

I note the OP hasn't gifted us with their code, so if he's doing
something wrong, we have to use our crystal balls to see it. It
is seldom good news.

--
Tough Guide Hedgehog
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/

[Richard Heathfield]

Walter Roberson said:

In article <1t******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>Mark Bluemel said:

>>Sounds like a limit in the input buffer size provided by your operating
system, not a C language/library issue.

>>If that's allowed by the Standard, what is the minimum such maximum input
buffer size? If none is stated, it effectively means that even hosted
implementations effectively don't have to provide stdin, since they can
simply set the input buffer size to 0, rendering it impossible to read
anything in!

C89 4.9.2 "Streams", Environmental Limits, indicates 254 minimum
for text streams (including newline.)

Ah, thank you. (I looked, but couldn't find it.)

So it seems that, if the OP's report is correct, his implementation has a
conformance issue.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Chris Dollin said:

Richard Heathfield wrote:

>It's at times like this that I'm tempted to shout "CHRISSSSS!!!"

C has no namespaces, so that's an ambiguous reference.

The One True Chris knows which one I mean. :-)

Also note
what Pterry has to say about multiple exclamation marks ...

Yes, but at least I stopped two short of bursarity.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

Richard Heathfield wrote:

Walter Roberson said:

>In article <1t******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>Mark Bluemel said:
Sounds like a limit in the input buffer size provided by your operating
system, not a C language/library issue.
If that's allowed by the Standard, what is the minimum such maximum input
buffer size? If none is stated, it effectively means that even hosted
implementations effectively don't have to provide stdin, since they can
simply set the input buffer size to 0, rendering it impossible to read
anything in!

C89 4.9.2 "Streams", Environmental Limits, indicates 254 minimum
for text streams (including newline.)

Ah, thank you. (I looked, but couldn't find it.)

So it seems that, if the OP's report is correct, his implementation has a
conformance issue.

I don't think so. The Standard requires that a text stream
be able to read a line of 254 characters, but I don't see this
as requiring that any particular input device must be capable of
generating such a line.

The C Standard is not to blame for the demise of the eighty-
column punched card.

--
Er*********@sun.com

[Richard Tobin]

In article <fl**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:

>>Do you mean input from a terminal? That may be limited by your
operating system.

An implementation shall support text files with lines
containing at least 254 characters, including the terminating
new-line character. The value of the macro BUFSIZ shall be
at least 256.

>As stdin is a stream and there is no exemption for stdin in the
above, an implementation that does not support lines of at least
254 characters on stdin is non-conformant.

The implementation must support 254 character lines on stdin, but you
may not be able to test that with a terminal. The ability of a
particular input device to supply long lines to a program is not
something the C standard can reasonably require.

Suppose a bar-code reader produces data in the form of a short
sequence of digits followed by a linefeed. Surely attaching this to
my computer in such a way that it can be used as standard input
doesn't render my C compiler non-conformant?

-- Richard
--
:wq

[Walter Roberson]

In article <fl**********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:

>In article <fl**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:

>>>Do you mean input from a terminal? That may be limited by your
operating system.

>>As stdin is a stream and there is no exemption for stdin in the
above, an implementation that does not support lines of at least
254 characters on stdin is non-conformant.

>The implementation must support 254 character lines on stdin, but you
may not be able to test that with a terminal. The ability of a
particular input device to supply long lines to a program is not
something the C standard can reasonably require.

>Suppose a bar-code reader produces data in the form of a short
sequence of digits followed by a linefeed. Surely attaching this to
my computer in such a way that it can be used as standard input
doesn't render my C compiler non-conformant?

However, in such cases, it would not be the *operating system* that
limited the input size below the mandated 254, it would be the
input device's inability to produce additional characters.
It has been many a year since I last encountered a *terminal* that
limited input size -- not since the mid 80's, using CICS
(or a relative thereof) with IBM terminals that were FEP
(front end processor) programmed with input "fields" of fixed length.

--
"I was very young in those days, but I was also rather dim."
-- Christopher Priest

[Keith Thompson]

su**************@yahoo.co.in writes:

I can not accept a string (without space) of length more than 127
whatever I do..

[...]

I don't think anybody in this thread has mentioned the problems with
gets(), probably because it was mentioned in the subject header but
not in the body of the article.

Never use gets(); it's a buffer overrun waiting to happen.
See question 12.23 in the comp.lang.c FAQ, <http://c-faq.com/>.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

In article <fl**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:

>>Suppose a bar-code reader produces data in the form of a short
sequence of digits followed by a linefeed. Surely attaching this to
my computer in such a way that it can be used as standard input
doesn't render my C compiler non-conformant?

>However, in such cases, it would not be the *operating system* that
limited the input size below the mandated 254, it would be the
input device's inability to produce additional characters.

The location of the boundary between operating system and device is
irrelevant to the conformance of the C implementation. if you contrive
to provide a long line on standard input, the C system will handle it.
That you can't do that by some particular method is none of the C
standard's business.

Do you think the compiler would be non-conformant if there weren't any
terminal devices?

-- Richard
--
:wq