flat assembler
Message board for the users of flat assembler.

Index > High Level Languages > gets after printf, seems to fail

Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 13083
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 0010456
sleepsleep 26 Apr 2010, 00:23
Code:
#include <stdio.h>

main(void)
{
    int n;
       char aa[10];
        
scanf("%d", &n);
printf("%d\n",n);
printf("AA : ");
gets(aa);
printf("%s", aa);
    return 0;
}
    


any idea, because of the printf("AA : ");
gets(aa) seems to fail.. ideas?

tried watcom and tcc... both same result.
Post 26 Apr 2010, 00:23
View user's profile Send private message Reply with quote
cthug



Joined: 03 Apr 2009
Posts: 36
Location: /home/Australia
cthug 26 Apr 2010, 01:28
You have a possible buffer overflow if you input 10 characters(because of the null termination), If not try debugging Wink.

NOTE: most compilers warn about using gets as it is not safe, if you are using gcc, it prints a report of stack smashing if a buffer overflow occurs
Post 26 Apr 2010, 01:28
View user's profile Send private message Visit poster's website Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler 26 Apr 2010, 01:53
It's not printf, it's scanf. scanf leaves the (cr)lf in the input buffer, which gets then reads, causing gets to terminate. Use scanf or don't use scanf, you just can't mix it with other stdin function because of it leaving the \n on the buffer and causing you problems.

cthug wrote:

[...] gets [...] is not safe, [...]

Neither is scanf, or most other commonly used libc input methods. Use fread because it allows you to specify the length of your buffer.
Post 26 Apr 2010, 01:53
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 26 Apr 2010, 12:44
Tyler,

scanf() works as specified. If programmer wants to skip the rest of input line, he should do this explicitly: "5Hello!\n" is valid input for the original program (almost overflows buffer, though).

scanf() is unsafe in the same sense as gets(): if you haven't specified field width, it's your problem, not libc; scanf() provides facility to do so, thus it's safer. Wink

----8<----
sleepsleep,

Tyler's right, gets() should be banished. fgets(), probably?
Post 26 Apr 2010, 12:44
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 26 Apr 2010, 18:00
Something might need to be added. Whenever scanf finds blank characters in format string, it skips all blank characters (including EOLs) on the input.
Post 26 Apr 2010, 18:00
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 27 Apr 2010, 07:27
vid,
  1. "%d " will consume trailing whitespace, but you have to enter both n and aa values together ("AA : " prompt won't be shown properly), and aa can't have leading whitespace;
  2. "%d%*c" will consume '\n' if it immediately follows number (if it doesn't, first character will be consumed and the rest became the input to gets());
  3. "%d%*[^\n]%*c" will consume anything up to '\n' inclusively.
The problem is, if '\n' immediately follows number, third format fails on second conversion specification and doesn't consume damn '\n'! Is there a way to make (assignment-suppressed) conversion specification optional?

while (!feof(stdin) && '\n'!=getc(stdin)); before gets() does it.
Post 27 Apr 2010, 07:27
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 27 Apr 2010, 08:25
baldr wrote:
vid,
  1. "%d " will consume trailing whitespace, but you have to enter both n and aa values together ("AA : " prompt won't be shown properly),


How so? You mean won't be shown properly in case when both stdin and stdout point to same interactive console? Or what?

Quote:
and aa can't have leading whitespace;

why not " %d " then? (Of course, this eats blank lines, so it may not be desired in some cases)

Quote:

  • "%d%*c" will consume '\n' if it immediately follows number (if it doesn't, first character will be consumed and the rest became the input to gets());
  • "%d%*[^\n]%*c" will consume anything up to '\n' inclusively.The problem is, if '\n' immediately follows number, third format fails on second conversion specification and doesn't consume damn '\n'! Is there a way to make (assignment-suppressed) conversion specification optional?

  • I didn't know about this. Is this standard C, or GNU extension?

    while (!feof(stdin) && '\n'!=getc(stdin)); before gets() does it.[/quote]
    Post 27 Apr 2010, 08:25
    View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
    baldr



    Joined: 19 Mar 2008
    Posts: 1651
    baldr 27 Apr 2010, 08:45
    vid,

    I mean "AA : " prompt won't be shown until you enter both n and aa values.
    vid wrote:
    I didn't know about this. Is this standard C, or GNU extension?
    At least ISO/IEC 9899:TC2 specifies this.

    fgets() / sscanf seems to be proper solution: first shows that program expects entire lines as input, second parses them.
    Post 27 Apr 2010, 08:45
    View user's profile Send private message Reply with quote
    revolution
    When all else fails, read the source


    Joined: 24 Aug 2004
    Posts: 20460
    Location: In your JS exploiting you and your system
    revolution 27 Apr 2010, 08:49
    Just roll your own proc. Problem solved.
    Post 27 Apr 2010, 08:49
    View user's profile Send private message Visit poster's website Reply with quote
    Display posts from previous:
    Post new topic Reply to topic

    Jump to:  


    < Last Thread | Next Thread >
    Forum Rules:
    You cannot post new topics in this forum
    You cannot reply to topics in this forum
    You cannot edit your posts in this forum
    You cannot delete your posts in this forum
    You cannot vote in polls in this forum
    You cannot attach files in this forum
    You can download files in this forum


    Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

    Website powered by rwasa.