Problem with scanf()/gets()

Discussion in 'C Programming' started by subratasinha2006@yahoo.co.in, Jan 3, 2008.

  1. Guest

    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
     
    , Jan 3, 2008
    #1
    1. Advertising

  2. Mark Bluemel Guest

    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.
     
    Mark Bluemel, Jan 3, 2008
    #2
    1. Advertising

  3. Mark Bluemel said:

    > 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
     
    Richard Heathfield, Jan 3, 2008
    #3
  4. In article <>,
    Richard Heathfield <> wrote:
    >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
     
    Walter Roberson, Jan 3, 2008
    #4
  5. Guest

    On Jan 3, 6:24 am, 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
     
    , Jan 3, 2008
    #5
  6. Walter Roberson said:

    > In article <>,
    > Richard Heathfield <> wrote:
    >>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 Heathfield, Jan 3, 2008
    #6
  7. In article <>,
    <> wrote:

    >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
     
    Richard Tobin, Jan 3, 2008
    #7
  8. CBFalconer Guest

    Richard Heathfield wrote:
    > Mark Bluemel said:
    >> 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
     
    CBFalconer, Jan 3, 2008
    #8
  9. In article <>,
    Richard Heathfield <> wrote:
    >Walter Roberson said:


    >> In article <>,
    >> Richard Heathfield <> wrote:
    >>>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
     
    Walter Roberson, Jan 3, 2008
    #9
  10. Guest

    On Jan 3, 6:24 am, 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?
     
    , Jan 3, 2008
    #10
  11. In article <flj0q3$30k5$>,
    Richard Tobin <> wrote:
    >In article <>,
    > <> wrote:


    >>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, Jan 3, 2008
    #11
  12. In article <>,
    Richard Heathfield <> wrote:
    >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.
     
    Walter Roberson, Jan 3, 2008
    #12
  13. Chris Dollin Guest

    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/
     
    Chris Dollin, Jan 3, 2008
    #13
  14. Walter Roberson said:

    > In article <>,
    > Richard Heathfield <> wrote:
    >>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, Jan 3, 2008
    #14
  15. 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
     
    Richard Heathfield, Jan 3, 2008
    #15
  16. Eric Sosman Guest

    Richard Heathfield wrote:
    > Walter Roberson said:
    >
    >> In article <>,
    >> Richard Heathfield <> wrote:
    >>> 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.

    --
     
    Eric Sosman, Jan 3, 2008
    #16
  17. In article <1199392278.479699@news1nwk>,
    Eric Sosman <> wrote:
    >Richard Heathfield wrote:


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


    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.
    --
    So you found your solution
    What will be your last contribution?
    -- Supertramp (Fool's Overture)
     
    Walter Roberson, Jan 3, 2008
    #17
  18. In article <flj9n6$j4n$>,
    Walter Roberson <-cnrc.gc.ca> wrote:

    >>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
     
    Richard Tobin, Jan 3, 2008
    #18
  19. In article <fljsa6$7e1$>,
    Richard Tobin <> wrote:
    >In article <flj9n6$j4n$>,
    >Walter Roberson <-cnrc.gc.ca> wrote:


    >>>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
     
    Walter Roberson, Jan 4, 2008
    #19
  20. 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) <>
    [...]
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 4, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Snubis

    Re: safe scanf( ) or gets

    Snubis, Jan 2, 2004, in forum: C++
    Replies:
    0
    Views:
    411
    Snubis
    Jan 2, 2004
  2. Teh Charleh

    scanf() vs gets()

    Teh Charleh, Nov 30, 2003, in forum: C Programming
    Replies:
    39
    Views:
    9,128
    Kelsey Bjarnason
    Dec 8, 2003
  3. Eric Boutin

    safe scanf( ) or gets

    Eric Boutin, Dec 14, 2003, in forum: C Programming
    Replies:
    57
    Views:
    3,608
    Gordon Burditt
    Jan 25, 2004
  4. =?ISO-8859-1?Q?Martin_J=F8rgensen?=

    scanf (yes/no) - doesn't work + deprecation errors scanf, fopen etc.

    =?ISO-8859-1?Q?Martin_J=F8rgensen?=, Feb 16, 2006, in forum: C Programming
    Replies:
    185
    Views:
    3,516
    those who know me have no need of my name
    Apr 3, 2006
  5. =?ISO-8859-1?Q?Martin_J=F8rgensen?=

    difference between scanf("%i") and scanf("%d") ??? perhaps bug inVS2005?

    =?ISO-8859-1?Q?Martin_J=F8rgensen?=, Apr 26, 2006, in forum: C Programming
    Replies:
    18
    Views:
    703
    Richard Bos
    May 2, 2006
Loading...

Share This Page