The definitive book on C, "The C Programming Language", now in its second edition, covers C89 and is still very relevant; you can learn later additions to the standard, most of which were either glaring mistakes or useful bits copied from C++, when you have a need for them. You can get it on iBooks, if you have that.

The tutorial I started out with was Coronado Enterprise's C tutorial which is very good for what it covers; it's also commercial. You can check out their other tutorials while you're there. The next best I have used is the C tutorial that accompanies LCC-Win32, which is also an excellent compiler to get you going generally, although of course no match for Visual C if you want the very latest interfaces.

Er. No.  See this timeline, since apparently knowing something isn't a qualification in these parts.  C needs a compiler, so merely knowing that a book about C existed in 1975 is sufficient to inform me that a compiler must have existed for it.  And we were more than moving on from punch cards by that point, all be it not yet at the point of home computers being anywhere near common.
As for compiling the programs, he said he can't.  This is sufficient proof that something is either wrong with the programs themselves, or they were written before C was standardized, modernized, and etc.  I am sure I could get them working if I put effort into it, if only by downloading older compilers.  I would not suggest someone new to the language try to do so.  One concrete example of an archaic feature that comes to mind is the old-style function declaration, wherein you use only types and the empty () means a function taking any number of parameters.  I can exclude the compiler because those have programmers working on them who know way more than everyone I know including myself put together.  I can exclude the programmer, because this is a transcription from a book which should be expected to know what it's talking about.  Given that the first C standard wasn't published until 10 years later and we hadn't yet seen the rise and dominance of the x86 processor, it is very logical to assume that a modern compiler--almost 40 years later!--might have trouble.  It is sad that I need to spell out my logic; I know these languages and their histories as well as anyone on these forums.  It is illogical to assume that a language with no published standard and no major dialect did not change in some incompatible way in the 7 years between 1975 and 1983, so I am very unclear what windows has to do with anything.
Also note that I gave a lot of helpful info, and I feel the warning is warranted in this case.  If you have a problem with my verbosity, I don't see how quoting my post helps.  If you have a problem with me personally, just say so and have done.  I felt obliged to say something because I've seen too many programmers think that they absolutely need to know these languages, try to learn them, and give up on ever learning another language again.  I have given my warning; if king gamer222 really wants to learn it I'll help him do so to the best of my ability.  I am the last person to say that these languages are useless or don't have a place.  They do: you sometimes really do need the performance.
But obviously arguing with you is pointless anyway.  I have yet to be on a thread where you have a problem with my opinions and provide good, logical, and concrete reasons they are incorrect.  You always attack me directly instead.  Doing so is not constructive; it merely places me in a position wherein I cannot defend myself without starting yet another war.  Sigh.
I will decrease my verbosity only when people stop saying that I am wrong without being able to tell me why.  I do not mind being wrong.  I do mind being told that I am wrong by someone who can not tell me why I am wrong and simply says that I need to "try things".  If I am verbose, it is because I have great need to declare and specify my reasons; if I simply say "x is good, y is bad", that carries no weight whatsoever.  Apparently I have yet to establish any sort of credibility, despite being one of the few people to ave any success providing 3D audio whatsoever.  Maybe I just need to go write a game before people will take me seriously here; apparently all my other programming is not sufficient to show that I might just have a clue in your eyes.

If you want to also discuss bloated languages, Perl is one such example. It basically looks like a bunch of spaghetti code and half the programs rarely function, which is odd. TTYtter is one such example. It even had a warning, but I was still surprised when it crashed.

@KingGamer: I'm surprised the K&R style code won't compile on GCC 4; I should look into that. Although, yes, you really want to learn the new ANSI declare-and-define routine, which is both more correct and clearer to read and understand.

Get "The Swift Programming Language" from iBooks, and save yourself the round trip of C. While I believe you should learn C, Swift was intended to be newbie-friendly and high-performing, and is geared up to win hearts and minds of future developers. Whether it will replace C as a system programming language is another matter, but it can work as such in the Apple ecosystem, which I still find astonishing.

if the goal is Swift, skip all the intervening stuff and just do it.  C will not help you learn Swift, save perhaps by making you a better programmer in general.  Swift is closer to Python than anything I know, but is still strongly typed and brings in attributes of all the other languages I know, too.
Objective-c is apparently a nice language.  I disliked it because of the verbosity and because XCode highlights every single problem I have with Mac accessibility, but nothing is really wrong with it.  While it, too, is a superset of C, you can skip right to it: you don't typically use char* and all the C libraries, as I understand, and it has some niceties like reference counting.  You need a Mac for both of these, though (sorta...you can technically run obj-c on windows, but...).
Assembly isn't worth your time unless you're coding for embedded hardware or doing some really hardcore stuff like OS development.  The modern x86 architecture is not aimed at programming in assembly anymore.  It's literally gotten to the point where your compiler can and will usually do a better job programming in assembly than you can--to get good performance out of it, you have to know about all sorts of stuff that I don't actually know myself, simply because there is no need for me to do so.  Examples of the ones I do personally know about include cache friendliness and unrolling and auto-vectorization of tight loops.
Go is an interesting language with a lot of unique features, and may not be a bad choice.  The problem with Go is that there are a few quirks that make it unfriendly to a screen reader user (whether or not a function starts with a capital letter determines if it is public is the big one here).  They can be worked around.  The big killer is that Go is a server language; nice enough to work with, but with few options for desktop libraries.  If the goal is a game, I'd suggest avoiding Go...for now.
I also dislike Perl.  It does indeed have a lot of little special cases, and at least one thing (file I/O as I recall) places very, very heavy emphasis on the difference between capital and lowercase.  Again, you can work around this.  The only language I haven't found an easy way to work around is Lisp, but the case sensitivity has semantic meaning bit is a big annoyance of mine.