char pointers and scanf()

char * userName; // Line 1 - reserve 4 bytes for the address of a char 
scanf("%s", userName); // Line 2 - starting at the address userName points
 // to, write bytes to consecutive addresses
 // until the user types <Enter>

Suppose the address stored in userName is X, and the user types Tron55555:
X->[T] X+1->[r] X+2->[o] X+3->[n] X+4->[5] X+5->[5] X+6->[5] X+7->[5] X+8->[5]

Is anything wrong with this picture? Maybe userName was even initialized to zero. Now at least we know where your name will be written in memory. Do you think the system is ok with the memory locations 0000 through 0008 containing (the ASCII code numbers for) tron55555? How bout if userName wasn't initialized. Suppose it contained the address 8720. Would the memory locations from 8720 through 8728 be a good place to write tron55555?

Think on this. Think about what the above code does, and decide if you want that in your program.
- Ray

char Username[32];
char *pUsername = Username;
scanf("%s", pUsername);

would be OK, as pUsername has been initialized.

char *pUsername;
scanf("%s", pUsername);

is not OK, because we do not control where pUsername points.

This is like calling for Pizza delivery, and then not telling the pizza place where you live. Only in this case, the pizza delivery guy still makes the pizza, and delivers it to some address written on the bathroom wall. You don't get your pizza, and they still charge your credit card.

OK, stupid analogy. Depending on the function you are calling, you must provide the storage for the values it returns. scanf("%s") requires a pointer to valid storage. Not just a pointer. A pointer is useless unless it points to something useful. An uninitialized pointer is like an address book without any names in it. It has potential, but otherwise useless (except I guess you could use it to level a wabbling table).

Computers are stupid. They only do what you tell them to do. And you have to tell them a lot, especially when working at the C level of programming. The good news about C, is that it can give you precise control. The bad news is, you have to be careful what you ask C to do, as it will do what you ask, even if you ask it to self destruct.

Tron55555 wrote:
In the second case, however, I'm a bit less clear on how it all works. Here, "userName" is a pointer to a single character (but this single character can be the first character in a series of consecutive memory addresses, which combine to store a string of characters, right?). So, what is the problem in telling scanf() to take the string of characters enetred by the user and to place it in those consecutive memory addresses?

A pointer must point somewhere. When you have a character array, that character array is the "somewhere" and the array variable can be treated "as if" it were a pointer. If you have a true pointer, it must be made to point somewhere before you can use it. It can point to a character array, some data allocated via malloc, or some other value.

All of the following are valid uses for a pointer. (Not all of them are advisable though).

char a[100];
char * p = & a[0];
char * m = (char *)malloc(100);
long l = 4;
char * dontusethis = (char *) & l;

The last one is particularly interesting. Not only does a pointer have to point "somewhere", that "somewhere" must be big enough for what you want to use it for. If you have an array of size 32, you can put at most 31 characters in it (because you need the null character to). In the last example, "dontusethis" is a valid string pointer but can only hold a string with up to 3 characters. It isn't very useful, but, as a pointer, it is just as valid as any other pointer.

Can you expand on this a bit? Why is that character array the "somewhere"? Wouldn't the array have the same problem if it was uninitialized that the char pointer had, or is there something different about the way char arrays are created internally that makes this not true?

A Character array is a container that can hold things. You can put stuff in a container and it will hold that stuff until you want it again.

As for being uninitialized, that just means do not look at the contents of the container (character array) until after you put something useful in it, otherwise it contains junk as well.

Since a pointer is only good if it is pointing at something, an uninitialized pointer is dangerous. Like gun safety: "always know where you are pointing it" (and never point it at your foot 🙂 ).

A pointer can point to different things. Its value is that what it points at can be changed, but the program only need to remember the name of the pointer. Pointers are useful in that you can pass the address of something really huge to a function, instead of physically copying the huge something to function local storage, having the function modfiy its local storage, and then copy the huge something back so the caller can see the change. Rather the pointer is passed, the function works through the pointer, and the caller sees the results when the function returns, without excessive argument copying.

Arrays of any kind, when passed to a function ALWAYS have the address of the array passed to the function.

An array that is assigned to a pointer will always give the pointer the array's address.

In many cases where you can use an array, you can use an initialized pointer. However, pointers change what they point at. You can perform "Pointer Math" on a pointer. Pointers are extremely flexible, but they do not hold stuff. They only point at stuff.

Tron55555 wrote:
Wouldn't the array have the same problem if it was uninitialized that the char pointer had, or is there something different about the way char arrays are created internally that makes this not true?

It sounds like you are confusing "allocation" with "initialization". They are very different. For example, the typical Cocoa object creation sequence is:

MyObject * obj = [[MyObject alloc] init];

Here, the first thing that happens is that the memory is allocated. Then, the allocated memory is initialized. Allocation is where your process asks the OS for some additional memory to use. Initialization is where the process assigns initial, valid values to the allocated memory.

When you create a character array on the stack via:

char array[100];

The array is allocated on the stack, but not initialized. Since arrays are just POD, not objects, they don't really need to be initialized. You can just start writing data into them. You could read data too, but it would be garbage.

A pointer is the same, you can assign a value to the pointer itself. That will make it point somewhere. But you can't use the pointer until you do so. Because an uninitialized pointer could reference memory anywhere, including inaccessible memory, it isn't as safe as an array. You can't even safely read the data from a pointer that hasn't been assigned a valid value. Where it points to is garbage and if you dereference that garbage (even to read it), you could likely get a bus error.

I think it helps a great deal to have had a wacky professor years ago who insisted we do everything in assembler. That really helps to understand these low level details.

Tron55555 wrote:
1.) The reason, as you said, that an uninitialized array will work with a function like scanf() is because arrays are "plain old data" and not objects, so they don't really need to be initialized. I'm assuming that means, therefore, that pointers, unlike arrays, are objects and not POD, which is why they do not work with a function like scanf() when uninitialized. Is this correct?

No, sorry 🙂

Pointer are plain 'ole data, but still a bit special - over and above objects. In C++, objects can be both on the stack and on the help, so all the same pointer considerations apply, even with objects. So, if you have a pointer to an object, the object must be allocated and initialized, and the pointer must be initialized as well - to point to the object.

A pointer is POD just because of the fact that it is probably the same size as a long data type. Most pointers reside on the stack just like a regular int, long, or double. Since they are already on the stack, they don't need to be allocated, but must be initialized before they can be used.

If you read an uninitialized int, you just get a garbage value. When you read a pointer, you are probably dereferencing it and, depending on the pointer type, could cause the CPU to choke and abort your program. That is the big difference.

For example, an integer must be on a word boundary in memory. An uninitialized pointer could have an odd address (like the value 3). That pointer could point to an integer. The CPU wouldn't like it if you tried to get the integer value that such a pointer references.

here's what confuses me about that -- consider the following code:

char * pChar = "Tron";

Here you are using the pointer before you've assigned an address to it, right? With character pointers like this, you seem to be able to use them before initializing them. Is this an exception to your rule, or does it just appear to be (to me at least) and there's a reason that it's actually not?

No, when you allocate a pointer on the stack (or any value) and do an assignment before the semicolon, that is an initialization. In this case, you are allocating your pointer on the stack and initializing it to the address of a string literal in memory.

This is a big deal in C++. Such a line of code would call only a constructor, not the assignment operator. It is important also because if you didn't do the initialization this way, the object would still have to be initialized with a default constructor. At best this is wasteful, at worse, it could be a serious logic error.

It isn't such a big deal in Objective-C because most objects can be constructed with just "init" and because complex constructors aren't used as much.

It is even less of a big deal in C, but the logic is still the same.

So, based on that, I guess what I'm asking is why does a char array work even if it's not initialized? Shouldn't the uninitialized char array have the same problem with the scanf() function that the uninitialized char pointer has? Does an array always point to something useful, even if it's uninitialized? Or is there a different reason? What's the reason that I can declare a char array and not initialize it and it works fine with scanf(), whereas if I declare a char pointer and not initialize it it does not work?

Because the character array "IS" the "Something"

scanf() wants a character array to store stuff into. scanf() assumes that the address passed to scanf() that is associated with the "%s" field is a character array. It is part of the rules set forth on the scanf() man page.

And scanf() is actually providing the initialization of the character array. Before scanf() does its thing, there was nothing useful in character array, so looking at it before the scanf() would not be a very productive thing.

NOTE: initializing a character array can be done a gazillion ways. Mentioning scanf() in this discussion is only because it is your topic title.

Another bad analogy. I have 2 bottles. In one bottle is a note, that says: "The other bottle has the water you want". In the other bottle is water.

The 1st bottle is a pointer. The 2nd bottle actually holds something.

I can take is a step further. A bottle has a note: "The left most bottle on the bottom shelf is the 1st bottle of an array, and each adjacent bottle contains fresh water, until you find an empty bottle and then any bottle following that has contaminated water. There you have a character array with a nul terminated string in it.

I have a function GetWater(). I copy the address of the bottle array into a register (left most bottle on bottom shelf), and then I call GetWater(). GetWater takes the address from the register, and dutifully fills each bottle starting with the "left most bottle on the bottom shelf" until GetWater() runs out of water (since GetWater() only has a gallon jugg, this happens before we use up the bottles on the bottom shelf. Before GetWater() returns, it empties out the next bottle it would have filled, as marker indicating where the fresh water stops. We now have described scanf("%s", char_array).

If we had stored "left most bottle on bottom shelf" in our bottle with the note inside, we could have called GetWater() by first copying the contents of the note into a register, and then making the call. The end result would have been the same, since our bottle with the note inside said "left most bottle on bottom shelf". GetWater() would not have known, nor cared where we got the address we put into the calling register.

NOTE: My analogy is going to start to break down in a moment, but I'll push on anyway 🙂

Now instead of a few bottles, we have millions/billions of bottles, each of which can hold notes, water, peas (addresses, characters, numbers). That is your computers memory.

Of course I used a single bottle to store an address, where as in your computer the bottles would be considered bytes, and it would take several bytes to store an address. I told you my analogy would break down.

RayNewbie wrote:
Would the memory locations from 8720 through 8728 be a good place to write tron55555?

Tron55555 wrote:
Sounds like the answer is no, but I don't know why. ...
So, what is the problem in telling scanf() to take the string of characters enetred by the user and to place it in those consecutive memory addresses?

Hey Tron -
I didn't mean to ignore your followup, in fact I've looked at the above several times in the past couple days, wondering how I could possibly get the missing concept across. Meanwhile I've carefully read the excellent explanations from Bob Harris and Et. My favorite is the pizza analogy!

But this effort has also been very frustrating for me, since as I wrote previously, this kind of discussion needs two people in the same room with a white board (and maybe a pizza as well).

Basically you're asking, "Why can't I store Tron55555 at the 9 consecutive memory addresses which start with the address that happens to be stored in userName?" What's different between these nine bytes and the 9 bytes that begin with the first address of userArray\[32\]??

I'll tell you the answer, but when you ask why it matters, I just don't know where to go:

The answer is that the address stored in userName is random, and more importantly _Not Allocated_ for the purpose of storing new data. This means that storing Tron55555 at that starting address is either going to raise an exception because that address is _outside the memory allowed for your program_, or else that address already _contains information your program needs_,

The concept goes to the very nature of what's known as "A stored program digital computer". A program always requires two things: Code and Data. When your program is loaded from disk, both the code and the data are written to memory. Where in memory? In a modern computer, that's decided by the "Operating System" (OS). Since many programs may be loaded into memory at the same time, the OS must assign specific blocks of memory to each program. When a program attempts to access memory outside this range, it's terminated with an exception.

But within the blocks of memory allocated to your program, there are also strict rules. Suppose the code for your program is stored in the memory block starting at 7000 and ending at 9000. What happens when you write Tron55555 right in the middle of that code block at 8720 through 8728?

Answer: The code that used to be in those bytes is overwritten by the chars of Tron55555. When the program gets to that code, the computer will read an instruction that's nonsense, and terminate the program.

Actually, in a modern computer, the memory containing your program's code will be marked "readonly", so the program will never get a chance to overwrite its own code. But the attempt will still terminate the program.

So what happens if 8720 falls within the Data section of your program? Well overwriting data doesn't do your program much good either. Maybe 8720 is the address where userArray\[32\], begins. If that array contained the characters "RayNewbie", it now contains "Tron55555". Of course that might be a change for the better. But in general, random changes to your data tend to be undesirable.

That said, I don't expect you to grok the concept of memory maps and memory management from what I wrote. These are big topics which are far more important than any one language or machine. The questions you've raised in this thread go to the basics of "What is a Computer?" and "How do Computers Work".

As much as I love to teach in this forum, and as much as I hope this forum is a place where people feel comfortable asking basic questions, if you want to understand these concepts, it's now time for you to enroll in a class. You need the basics of what a computer actually is, and then, if you really want to understand what you're asking in this thread, you will find the answer in a class on Assembly Language.

You're going to make everyone crazy if you keep nibbling at these concepts, one C statement at a time. These threads never really end, though mercifully you've chosen to close a few after 20 or 30 responses. If you keep flailing away, I and everyone else here will try our best, but you're wasting your own time by trying to deal with this kind of question in a forum.

Most students will just accept that char*userName; creates a variable that doesn't point to a legal allocation. But you want to know "Why? And what's a legal allocation, anyway??". That's no longer a C question. That's a basic question about how computer's work. I think you're going to be a great programmer if you keep wanting to know how everything works at a low level. But you'll never get that from a forum. And mining it out of books isn't the way to learn it either. When you write assembly code that's graded by a live instructor and discussed with your colleagues, everything you're asking here and much more will suddenly be easy for you.

\- Ray

Tron55555 wrote:
Thanks for the explanations. The only question left that I would have is, given your explanation about how anything before the semicolon is an initialization, then what about if you put the assignment on a separate line, like:

char * pChar;
pChar = "Tron";

Then you have two actions. You are allocating the pointer, but not initializing it. Then you assign a value to the pointer. It is more wasteful in lines of code than anything else. One of the things that keeps Objective-C simple is that objects are always pointers. Pointers are simple data types and very easy to deal with. The above two statements in C++ would be an entirely different discussion.

RayNewbie wrote:
But this effort has also been very frustrating for me, since as I wrote previously, this kind of discussion needs two people in the same room with a white board (and maybe a pizza as well).

When is that going to happen? You are glossing over a huge issue. How does anyone learn programming? Not in a big lecture class. Not on the job - no one is going to go over details like this at work. (Not really true, but I'm trying to make a bigger point). Programmers are expected to learn how to program on their own. There is a reason why modern software is so bad, bloated, and buggy - no one knows how to do it! The software development industry has serious problems and training new programmers is one of the biggest.

As much as I love to teach in this forum, and as much as I hope this forum is a place where people feel comfortable asking basic questions, if you want to understand these concepts, it's now time for you to enroll in a class. You need the basics of what a computer actually is, and then, if you really want to understand what you're asking in this thread, you will find the answer in a class on Assembly Language.

I don't disagree with anything you've said here, but it is definitely easier said than done. Schools don't teach assembly anymore. They barely even teach programming. Programming is a "skill" that students are expected to "pick up on their own" in most computer science programs.

You're going to make everyone crazy if you keep nibbling at these concepts, one C statement at a time. These threads never really end, though mercifully you've chosen to close a few after 20 or 30 responses. If you keep flailing away, I and everyone else here will try our best, but you're wasting your own time by trying to deal with this kind of question in a forum.

I much prefer answering Tron's questions than the old "I spilled soda pop in my Macbook Pro and now it won't turn on!"

Most students will just accept that char*userName; creates a variable that doesn't point to a legal allocation. But you want to know "Why? And what's a legal allocation, anyway??". That's no longer a C question. That's a basic question about how computer's work. I think you're going to be a great programmer if you keep wanting to know how everything works at a low level. But you'll never get that from a forum. And mining it out of books isn't the way to learn it either. When you write assembly code that's graded by a live instructor and discussed with your colleagues, everything you're asking here and much more will suddenly be easy for you.

Unfortunately, that last part is never going to happen either:)

I happen to think that this forum is one of the better ones. There are certainly some good computer science programs, some of which may even have assembly classes, but there are a whole lot of bad ones too. Don't expect to learn anything about memory allocation in a C# class.

The squeaky wheel gets the grease. As long as you get good answers here in the forums, keep asking questions. If Ray or I get tired of answering, that will just give someone else a chance to answer. Try to find a good computer science program to enroll in too. You will learn a lot there. However, you will still have questions that your colleagues can't answer, your TA doesn't understand, and your professor doesn't have time to answer.