K&R is not intended to be a complete manual for every function in the C library: that's what man pages are for. K&R is a tutorial that introduces the C language (that is, the things that compilers deal with -- keywords, data types, syntax, ...), and shows some ways they can be connected together to make working programs. There are countless libraries that C can call: X-windows graphic libraries, and encryption libraries, and database access libraries, and networking libraries. They all come with their own manual pages. If the C Language book covered all those, then (a) you would not be able to lift it, and (b) it would be permanently out of date, as things evolve. My K&R is a First Edition from 1978, so the page numbering is not going to be the same as yours -- I'm not sure the section numbering will even be the same. That's why you use your own volume's index. Section 7.4 "Formatted Input" in mine covers scanf, 7.5 for sscanf, and 7.6 for fscanf. They are very similar, and use the same format "conversion specification" options: scanf reads from stdin, fscanf reads from a file, and sscanf reads from a string in memory. They work best for input where you are not too fussed about how it fits into input lines, so they are quite sloppy about whitespace. getline appears in section 1.9, as an example of how to write a function in C, and again in section 4.1 which is about how to structure a larger program. At the time, there was no standard library function getline(). When this was added into a library later, it was made to do the same kind of thing, but allows for expanding the input length automatically. So getline() reads a whole line from a file (which can be stdin or any other file or device), but it does not unpack any fields or values itself: there are a whole family of other functions that deal with those things. Some of those functions have names like strtok, strtol, strtod, and they all have man pages. Usually, there is a "See Also" section that links you into similar or related functions. fgets() is in section 7.8 "Line Input and Output" along with fputs(). fgets() is like getline, but simpler: you provide space for the string, but if it is too short you don't get a whole line of data, and you have to deal with that problem yourself. gets() is like fgets() but for stdin only. Also, it does not care at all about the space you provided for the input, and so can be misused to corrupt your program. The first four words in the man page are "Never use this function". All the code sections you posted are wrong, and here's why. char name[100000000]; reserves a buffer of 100 million characters as a local (on-stack) variable. That will use up all your stack and more besides, and your program won't run (probably not even load). char *x; would create a pointer to some chars, but it is not initialised to point to anywhere -- it is a pointer to something that does not exist. char **x; is even worse: is is a pointer to a pointer that does not exist, that would point to some chars that don't exist either. string x; uses a type "string" that does not exist in C. Some CS50 courses provide a header file that fixes up stuff like "string" to make your code easier to write, but they are not proper C and they hide the actual details, which is a piss-poor way to learn. scanf ("%c") reads exactly one character from the input. That is not a string. scanf ("%s") reads a string (like a name) from the input. It reads a real word: it skips any preceding whitespace, and it then only fetches text up to the next whitespace. Also, second example says #inclue and misses a ; off the scanf line, third one says scacnf, fourth one misses ; off scanf and a closing } . Compilers don't allow for carelessness. "string" is not part of the C language. It is verbal shorthand for "A row of text characters that ends with a zero (ASCII NUL) character. A row of things in C is usually called an array. To read and show a name in C, this would be good: #include int main(void) { char name [84]; //.. Allowing space for NUL terminator. printf("What's your name?\n"); scanf("%80s", name); //.. Limit field width on read. printf ("Good to meet you, %s!\n", name); } OK, I've spent 75 minutes writing this up. You need to do some work now. K&R is quite readable -- worth skimming the whole thing just to get an idea of what is in there -- get the shape of the language and fill in the detail later. Those dumb tutorials you found are mainly written for vanity by people who don't understand C themselves. 80% of it is junk. It really is worth reading enough man pages to understand why the information is presented like they do. More on reddit.com

First: C has no type for strings. It does not, simply out, have strings. Print functions expect a sequence of contiguous chars with a null (0x00) at the end. The same for strings length and other “string” functions. Second: the two first sentences do the same, they declare a variable as a pointer to a sequence of chars and in the same line it assigns a constant value where each element is one of the chars of the string and add a 0 at the end. So you can do string1[4] and string2[3]. Primitive value array pointers can be seen as an array or as a pointer indistinctly More on reddit.com

C does have strings. It doesn't have a "string data type", but it has strings. A string object in C is not a string because the type system says it's a string, it's a string because of the nature of the bytes that make up the object. Specifically, a C string is "a contiguous sequence of characters terminated by and including the first null character". That definition makes no reference to types at all. This might sound a bit pedantic, but it's actually pretty important. Let's say you have an object declared as follows: char str[100]; Does this object identify a string or not? We cannot answer this unless we know the value being stored in the object. The value might be a string, or it might not be. The type system does not tell us. Somebody just asked me "what is a character in C"... but then they deleted the question. I suspect it was going to lead on to "isn't char a data type?" Yes, char is a data type. But in C a character is given the somewhat more abstract definition "member of a set of elements used for the organization, control, or representation of data", as well as the practical definition of a value stored in a single byte. Essentially I see the notion of a character as being a description of a value, not the type of that value. Characters are often stored in char objects, but they can also be stored in other type objects, like unsigned char and int. For the "character as an element of a string" sense, however, one must think of these characters as being in contiguous bytes in memory. One might typically use a char pointer or an array of char to denote such an object, since they allow you to directly address each character in the string individually. A void pointer would not let you do this so easily, for instance, even though it could just as well point to the first character of a string. More on reddit.com

You’re just having an argument over what the definition of “string” is. Your argument has nothing to do with C. It’s what people are talking about when they say “arguing over semantics”. These arguments, where you both agree about what the truth is (you agree how C works), but you disagree over the semantics of the words you use to describe C (you disagree about what a “string” is). The C standard is not going to decide this argument for you. Neither is the dictionary. More on reddit.com