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]

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:

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!!!"

 

[Walter Roberson]

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.

 

[fred.l.kleinschmidt]

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.

 

[Richard Heathfield]

Walter Roberson said:

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 Tobin]

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

 

[CBFalconer]

Mark Bluemel said:

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?

 

[Walter Roberson]

Walter Roberson said:

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

 

[mrdarrett]

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]

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.

 

[Walter Roberson]

Mark Bluemel said:

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.)

 

[Chris Dollin]

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.

 

[Richard Heathfield]

Walter Roberson said:

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]

Chris Dollin said:

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>

 

[Eric Sosman]

Walter Roberson said:


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.

 

[Walter Roberson]

Richard Heathfield wrote:

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.

That's a good point, and one that suggests an interesting test
for the original poster: use whatever system-dependant mechanism
is necessary in order to redirect stdin from a file, and see if
the 127 character difficulty still shows up.

We have not seen the original posters code yet, so it is still
a bit early to conclude that the difficulty is in the poster's
system's stdin handling rather than in the poster's code.

 

[Richard Tobin]

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

[/QUOTE]

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

 

[Walter Roberson]

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.

 

[Keith Thompson]

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/>.