@23
This is wrong. Specifically compare the return value to 1. Scanf will return non-zero values for errors which will be counted as true.

Edit: Missed the not.  But that's still wrong, because EOF is usually a non-zero value.  Compare to 1. Anything but comparing to 1 is wrong in this instance.

Oh, my bad. Will fix ASAP. Will keep the original post intact for post history sake.

@31, thanks.

You'll probably want to pass the board as a pointer along with the width and height, then do int value = board[x*height+width].  You can't pass arrays by value; if you want to do that, you'd do something like:

struct Board {
    int *data;
    size_t width, height;
};

int readBoard(struct Board *board, size_t x, size_t y) {
    return board->data[board->height*x+y];
}

then use memory allocation functions to allocate board.  ALternatively, put the array in the struct, which stops a thing called pointer decay from happening.

You want the width as well because that will let you check whether x is right--in practice you'd have a debug-only bounds check here with assert or something.

I had to look up the semantics, but basically arrays are converted to pointers when passed to functions, and int board[] is just a fancy way of saying pointer to int.  I had to look it up because it's not done in practice, since (in C at any rate) you can't make a function that works on any size of array.

C and C++ are different as well.  (most) C compiles as C++.  Very little C++ compiles as C.  C++ is something like literally 10 to 20 times as complicated as C.  I'd not try to get C++ resources teaching you C for that reason, though in this case you'd have the same problem in C++ as far as I know.  C++ people have a set of solutions to this that are sort of better, but explaining non-type template parameters is very much not worth it until after you've had 5 or 6 other explanations of C++ things.

You can put the array in a global variable (i.e. outside of any function) and then all the functions can just use it.  if this is a college/school setting, I doubt your professor intended for you to start trying to pass multidimensional arrays around without a proper explanation of pointers.  In C, arrays are actually barely better than raw memory, and they're not super useful for encapsulation unless either in a struct or used as pointers.

If you want to try to understand, consider how you'd write a function that took an array of any size without being passed the size while the program is running.  I don't know how to put this particular insight into words, but it's an important one to grasp.  Start asking yourself how the language has to implement the thing, and you can start getting a feel for the why of C and not just the how.  C never does anything for you, ever.  If the answer you arrive at is "the compiler would inject magic instructions to make this work for me" that's usually the wrong answer.  The situation with arrays in C could be a little less confusing, but it's actually damned near impossible to make it useful without the compiler doing magic for you at runtime or some advanced features that C doesn't have for describing types.

@37, no, that only works on static arrays (allocated during compile time), and isn't actually correct. This is how you do it for static arrays:

//...
const char* versions[5] = {"1.0", "1.1", "1.2", "1.3", "1.4"};
// sizeof(versions) / sizeof(versions[0]) == 5

This, however, is not correct, and is an error in GCC (-Wall -Wextra -Werror):

char** versions = malloc(5*sizeof(char*));
for (int i = 0; i < 4; ++i)
versions[i] = malloc(4*sizeof(char));

strncpy(versions[0], "1.0", 4);
//...
// sizeof(versions) / sizeof(versions[0]) == error

Notice the use of the malloc and strncpy functions. If you don't know, malloc allocates uninitialized memory, and strncpy copies characters from a source to a destination. strncpy is a (slightly safer) alternative to strcpy, which is less safe and does no bounds checking. strncpy requires that you pass in the length of the string your copying, and will only copy the amount you specify. Same with functions like snprintf vs. sprintf and strncat vs. strcat. On the links I've pointed you to you will notice functions like strcat_s, strncat_s, etc. Don't use these functions; only Windows actually implements them (and they don't exactly offer any advantages, though they claim to). You can either start using functions like malloc/strncat/snprintf now or later; you might've already started.

So I have taken Camlorn's advice and been looking at pointers off and on today. They don't seem too terrible from a conceptual standpoint. My questions are below:
1.   What happens if something like this gets executed?

int number = 5
int * pNumber = number;

Obviously, we're missing the & before number, but what happens when I try to dereference pNumber? When I tried to print the value of the pointer, the program just froze for a bit and exited without any complaints. No output was shown, which is expected, but no error messages were raised during compilation or runtime, either.
2. Do I always, always, always have to do this even if I know with 100% certainty that my pointers will never be NULL?

int number = 5;
int * pNumber = &number;
if (pNumber) {
    //...
}

3. What is the use of having constant pointers? I.e

int number = 5;
const int * pNumber = number;

It seems pointless because I can still change what the pointer points to, I just can't change the actual address of the pointer, i.e

//Combined with our previous example
int number2 = 6;
pNumber = &number2;

When would I ever use this?
4. Going by the same note, why would I use the following?

int number = 5;
int * const pNumber2 = &number;

Yes, that is perfectly legal as far as I know.
5. So I now understand what y'all meant when you said when saying pointer to array relationship. Trouble is, I am now confused as to how to loop through an array

int values[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int * pValues = values; //Points to the first element in the array
//Now, I can do this:
for (int i = 0; i < 10; i ++) {
    pValues ++;
    printf("%d\n", *pValues);
}

That will go through the array, but it will also add in another variable, i, which I might as well use to subscript the array to access the values. So, what's the point of having a pointer?
I can't do this:

for (; pValues < 10; pValues ++) {
    //...
}

From what I gathered, if I just type in the pointer name, the compiler will think that I am trying to access the address in memory the pointer points to (a hexadecimal representation which will not equal 10).
So what am I missing here?
That's as far as I've gotten today because of the headaches of the const int * pointer and int * const pointer. Oh, and you can also do const int * const pointer, too, which doesn't help me at all when trying to process the information.

So, part 2 is const.

The idea of const is that you are promising that a variable (or a pointed-to thing or etc) won't be modified.  There's two ways of using const:

const int x;

and:

int const x;

The first is convenient shorthand for the second, which will also apply const to all the variables on the same line, but for the sake of explanation (though not really for the sake of real code) we're always going to use the second for the moment.  The rule is that the first kind of const gets rewritten to the second kind of const, and then const affects what's immediately to the left.  So, some examples:

// a constant int.
int const x = 0;
// or:
const int x = 0;

// A pointer to const int.
//This is a promise that this pointer only reads data. You can change its address, but you can't write through it--the comiler will stop you:
int const *x;

// A pointer that can be written to, but whose address can't be changed:
int *const x;

// And this can't have its address changed, and can only be read from:
int const *const x;

Now I'm going to digress a bit for a second.  There is a concept of a side effect in programming, for the sake of simplicity let's call them "expressions that do things".  Side effects are:

1. Reading from/writing to memory in a way that can change if the same line of code is run twice; and
2. Doing some form of input/output.

The thing about const is that what const does is says that after the declaration you can't change the variables in ways your variable declaration wouldn't allow, but you can (and always, always should) initialize it, even to an expression with side effects.  That is:

int const x = getNumberFromFile();

Is perfectly valid.

Now you might be asking "does this exist at runtime?" It doesn't.  It has two main uses.

First, it prevents you making mistakes.  There is a practice called const correctness, which basically means that you put const everywhere it makes sense to.  If you do that, the compiler will catch you if you try to change something that shouldn't be changed, i.e. a global constant variable, to name one common use.  Additionally, when you get into structs, you will discover that const lets you make some fields of a struct read-only.

Second, when you use it in function parameters, it provides documentation and a weak guarantee.

The documentation tells the user in what ways the function will change its arguments, which isn't super important for non-pointers, but for pointers there's a big difference between foo(int *p) and foo(int const *p) because the latter says "I swear I will not touch the int you passed me".  Ints are actually smaller than pointers so that doesn't make sense, but for large structs this is important since if you don't pass a pointer you might be copying hundreds of bytes, and the const on the pointer says that the caller should just go ahead.

The weak guarantee is that the function taking the const parameter can't make changes, at the compiler level.  This is weak because you can actually get around const if you want, and there  are even some good (but advanced and very raree) times you should do that.  This doesn't actually just extend to expressions, it also makes you incapable of passing those values to other functions that might want to make changes.  A really big one here is free, which takes a void* instead of a const void*, that is to say a non-constant pointer to anything as opposed to a constant pointer to anything.  Why? Because the change that free makes is it takes all the bytes pointed to by the pointer and makes them become invalid bytes.

So some places you'd want to use const: on global variables that hold values that don't change for starters.  If you compute sizes of objects, that's another good place: presumably the size isn't going to change.  It's hard to give examples because const correctness is a sort of I know it when I see it thing.

But beyond being there for you (and one day, if not now, you will understand that it's actually your friend even if it is annoying) it mostly doesn't do anything.  Poor C compilers can use it as a hint for optimization, but things like GCC are now advanced enough that they don't bother looking at it to my knowledge.

Nope!  You can subscript pointers.  It works fine.  The following two expressions are exactly 100% equivalent in every way:

p[i]
*(p+i)

and most coders use the former for clarity.

Yes, that does mean these are equivalent too:

*p
p[0]

And disturbingly, so are these (never ever do this):

i[p]
*(i+p)

I don't know why the last is allowed.  Probably something something something history something X86 assembler syntax.

The thing you can't do is subscript a pointer twice, i.e. treat it as a 2 dimensional array.  The first subscript of an int pointer is an int, which can't be subscripted further.  Yes, pointers to pointers do in fact exist, and you will get there shortly.  Indeed I have once or twice needed a pointer to a pointer to a pointer to foo.  If you have more than one level of pointer the subscripts always remove one level, so a int **x can be subscripted twice, an int ***x can be subscripted 3 times.  It is okay if this particular paragraph gives you a headache for a while; lots of people have trouble with pointers to other pointers.

Ah, I understand now.  Thank you so much for your help. I don’t know where I would be without all of your explanations.
I am going to proceed to quickly forget the last example. Why would anybody use that.

@47, technically there still are 20-30 architectures out there; the majority aren't really competing thoug. For instance PowerPC is still actively developed (I know of a fully open-source computer, with a fully auditable computing domain, for instance). RISC-V is another one, though RISC-V is more of an academic architecture (though I wish it got more widespread use, it looks to be pretty nice).