3

Shouldn't I get an error if my string goes over 9 characters long in this program?

// CString.c
// 2.22.11

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

main()
{
    char *aString = calloc(10, sizeof(char));

    if (aString == NULL)
    {
        return 1;
    }

    printf("PLEASE ENTER A WORD: ");
    scanf("%s", aString);

    printf("YOU TYPED IN: %s\n", aString);
    //printf("STRING LENGTH: %i\n", strlen(aString));
}

Thanks

blargman

nambvarun
  • 1,201
  • 4
  • 13
  • 14
  • what you are passing scanf is a pointer .. and c run time doesn't hold any information on size of allocated pointer ... well it may hold that data .. but it's inaccessible to standard C programs... you may be able to use heap introspection features to get available size) – vrdhn Feb 24 '11 at 04:05

2 Answers2

5

You don't get a compiler error because the syntax is correct. What is incorrect is the logic and, what you get is undefined behavior because you are writing into memory past the end of the buffer.

Why is it undefined behavior? Well, you didn't allocate that memory which means it doesn't belong to you -- you are intruding into an area that is closed off with caution tape. Consider if your program is using the memory directly after the buffer. You have now overwritten that memory because you overran your buffer.

Consider using a size specifier like this:

scanf("%9s", aString);

so you dont overrun your buffer.

Marlon
  • 19,924
  • 12
  • 70
  • 101
  • 2
    @blargman: **Undefined behavior means** ***anything*** **can happen**. That includes allowing your program to work. It also includes crashing your computer, causing your cell phone to explode, stopping the rotation of the earth and bringing Hitler back to life. In other words, "undefined behavior" means "there's no guarantee that this will work the way you want it to." You cannot rely on undefined behavior to give you the expected behavior consistently. – In silico Feb 24 '11 at 04:06
  • @blargman: There is no guarantee about what your program will do. What's happening now is that you're writing to memory you didn't properly allocate. Anything could happen, from working perfectly, to the program crashing. – Nicholas Knight Feb 24 '11 at 04:07
  • 1
    So, is this an instance of buffer overflow? – nambvarun Feb 24 '11 at 04:14
  • 1
    @R..: Exactly. UB means *anything* can happen. (I was hoping that someone caught that.) :-) – In silico Feb 24 '11 at 04:15
  • Also note that using tools like Valgrind or Purify can help detect this type of error. – Raph Levien Feb 24 '11 at 04:22
  • 1
    @blargman Yes, exactly, it's an example of buffer overflow. C is an ancient and primitive language that does not maintain, and thus does not check, the lengths of arrays ... if you write past the end, the data overwrites something ... other variables, code, there's no telling. If you find something so unsafe to be unsettling, consider using a more modern language. – Jim Balter Feb 24 '11 at 11:26
1

Yes, you got an error. And the most unfortunate part is that you don't know about it. You might know about it later on in the program when something mysteriously crashes (if you're lucky), or when your client's lawyers come to sue you (if you're not).

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711