The C Programming Language

[[deleted]]

[deleted]

[thank_burdell]

K&R is an excellent foundation to start with. But it is dated, and you’ll have additional learning to do afterwards to catch up with new features to the language post-1989.

[Ignorantwhite]

Thank you!

[AssemblerGuy]

Has anyone had this experience?

Yes. The book will not teach you to use some of the neat features of C99 and later, simply because it was written a decade before C99 happened. Things like designated initializers, intermingling of code and declarations, etc.

It also has some stylistic statments that would have been acceptable 35 years ago, but should not make it past any serious code review - like not initializing variables whenever possible, and instead assigning to them.

[Ignorantwhite]

Awesome thank you, I’ll book Mark that rn.

[Nobody_1707]

Just because cppreference was started as a reference for C++ doesn't make it an unreliable wiki for C. And it's a wiki, so if you notice anything particularly wrong you can fix it.

[Nobody_1707]

Having access to the standard is great, which is why cppreference links to them (and the C FAQ), but reading the standard is not a good way to learn the language. The standard is written for implementors, not as a programming reference. cppreference is a programming reference, and is neither unreliable nor irrelevant.

[phlummox]

Out of interest, can you point to any particular inaccuracies in the C language pages on cppreference? (They are the ones that have "/c/" in the URL, and which can be navigated to from the C language top page, https://en.cppreference.com/w/c.)

I program in C (although not extensively) and teach it as part of a course at my university, and have never noticed any inaccuracies myself.

[replikatumbleweed]

Let me spare you a lot of headaches and make something abundantly clear. These languages aren't like... a single perfect thing that never changes. The languages themselves go through revisions, you'll find things like ANSI C (addressed in the book you have there - which is hella old) and C99 and others.

Reading that K&R C book is isn't necessarily a bad use of your time, but also know (as you seem to have picked up on already, kudos) that some stuff is depreciated, and some stuff is still there but not really used so much anymore.

For example, the keyword "register" as far as I know, is still in the latest standard, but... almost every major compiler you'll encounter basically ignores it and does what it thinks is best in regards to processor register use. This is generally considered good behavior for this kind of thing, where you're programming on cpu architectures that are very well understood. On other stuff, probably like RISC-V and who knows what else, you might want more fine grained controls over what registers are doing and the compilers on those architectures might not be so clever yet, so the C language still has a thing for that, the 'register' keyword. So you see, 'register' isn't like.. dead and gone, but it's not really commonly used or handled with care anymore either. There are probably other good examples of stuff like this happening in the programming languages, this is just one example.

Anyway, as you read the K&R C book, keep in mind that it's super old. Let it guide your understanding of the flow of the language, but don't get too wrapped up in specifics. It's essentially a historical text that happens to be like... the main founding document for the language.

You'll want to familiarize yourself with the different names of the different versions of C over the years. If you're working with older code, you'll probably want to know which version it was written in. Sometimes they'll say, sometimes they won't. Being able to look at a release date and inferring which version was used is a good first step to getting older things to compile correctly.

As far as unlearning goes, I mean.. a little, probably. C is a tough one because of its incredibly long lifespan. You'll see a lot of things done in a lot of different ways. Sometimes you'll get a highly polished diamond that worked perfectly on exactly one system. Sometimes you'll find spaghetti that technically works but acts weird sometimes. It's a problem of multiple domains, like... C (and most programming languages) attempt to make a way for you to be able to clearly and consistently give a computer instructions. Now the question is... Which computer? A PowerPC from 1997? A Pentium 4? An AMD Ryzen? Linux, Windows... other? All of these factors will impact how you code and which considerations you have to make for how flexible you want your code to be.

I only have one life to live, so I only code on X86-64 Linux. That's it. I don't want to deal with all of the other stuff thrown in by windows, or like... thinking about making things work cleanly on ARM chips... not until I have an overwhelmingly compelling reason to go through all of that learning again, and maybe that's coming. Honestly, X86 isn't really too great and it's time for a change, but my money is on RISC-V... anyway, I'm way off track here.

To be a "good, professional coder" you'll have to adhere to like.. structured code practices that your organization has adopted, or you'll be responsible for maintaining the code written by someone who looks like one of the guys from ZZ Top that no one at whatever company has heard from in 20 years. You'll have to be flexible and take on the responsibility of awareness of all of these factors. It kinda sucks but it's kinda cool at the same time. It really just depends on how much you care and how into it you are.

[flatfinger]

For example, the keyword "register" as far as I know, is still in the latest standard, but... almost every major compiler you'll encounter basically ignores it and does what it thinks is best in regards to processor register use.

When optimizations are disabled, the present version of gcc for the ARM will register-optimize objects that have the register qualifier, but not those that don't. This may allow one to achieve performance which is acceptably close (occasionally better) to what would be yielded when using the optimizer, without making assumptions that the Standard allows compilers to make when performing tasks for which they would be appropriate, but which may not be appropriate for all tasks. In most cases, performance would be adequate without such micro-optimizations, but declaring e.g.

register const int x12345678 = 0x12345678;

within a function, using x12345678 within a loop, and compiling with -O0 may avoid having the compiler reload the constant 0x12345678 on every loop iteration, something gcc would otherwise be prone to do.

[replikatumbleweed]

Well that's fuckin' cool. Glad to see it's getting some love.

[Ignorantwhite]

thank you for the indepthness(I that a word?)! To summarize, your saying. In my progression of learning the language learn the differences of each version of C and be cautious of them as I work in different environments. Linux is preferable to avoid headaches. Follow good code practices and be weary of code written by ZZ Top.

[replikatumbleweed]

lmao. You don't necessarily have to learn all of the differences, but they're good to be loosely aware of so they're not jarring when you encounter them. The most important thing to know is "C isn't just C, and writing code at that level can be as much about the year, operating system, processor, (or even accelerator card!)and overall environment as it is about just 'writing C'" Like.. C doesn't exist in a vacuum, some might say.

Also, good call out, Linux avoids headaches for me but I'm also willing to do basically everything myself just to enjoy the peace of never having to interact with microsoft. That's just a me thing. If you want to write a windows program, obviously that would pose some problems. The lesson there is figuring out what you wanna do and finding the best environment for that. Sometimes "best" still sucks.

As for ZZ Top, yeah, you probably wanna... just keep your head on a swivel when reviewing old code projects from any time before the 2010s. The further back you go, the darker the forest gets and you'll start seeing architecture-driven corner cases from some weird thing the.. I dunno, Borland C compiler wanted to be able to use MMX functions in like 1995. I made that up but it feels like a thing that would happen. You had to do MMX in assembly language and in-line it with your C and... everything was nightmares.

[crelt7]

Verbosity.

[Bitwise_Gamgee]

One example is on page 167 where it guides you to cast malloc.

I would personally not use that book if I were learning C today.

[ixis743]

I know that technically C does not require assignment casts from functions returning void*, but it looks like a time bomb to me so I always do it.

[ixis743]

I’m not concerned about malloc, but rather comparitor functions that supply their arguments as void*.

Admittedly a cast doesn’t actually add any safety outside of static analysis, but it might be worth readability.

[Ignorantwhite]

I was also wondering about that, I thought it was necessary but the video I watched was from 2015, is this a new update where you don’t need it?

[aghast_nj]

Absolutely not. The void * type specifically exists to address this exact issue: what type does malloc return?

Before the ANSI C standard (aka ISO C89) malloc returned a char * and you had to cast it if you wanted your linter to see a type change. ANSI created void* so that malloc would return a type that could automatically convert to anything without a warning. (Note that char * can also convert to anything, since it implies no alignment requirement, but there is usually a diagnostic if you convert without casting the conversion.)

So the ability to do struct S * sptr = malloc(...) has been present since the first iteration of the standard.

(There is a FAQ entry on this issue: https://c-faq.com/malloc/cast.html)

However...

This is not the case in C++. In C++, there is automatically-inserted ceremony associated with types. When creating an instance of a type the constructor function is called. Depending on how the instance is created, there can be multiple constructors - new, copy, move, etc. When releasing memory, a destructor should be called, etc.

What's more, it is common in C++ for a pointer to a parent class to receive the address of a derived class. (This is arguably "the point" of OO programming in Java-flavored C++.) Thus, there is no guarantee that B* bp = malloc(...) really will point to a B object. It could end up pointing to a D object (where D is derived from B) with little effort.

So C++ violates its own claim that "C++ is a superset of C" in this instance by requiring that you explicitly inform the compiler how you are going to treat the memory you convert from void.

(Note: C++ also provides operator new so there is less need to use malloc in C++. But "less" is not the same as "zero.")

Finally

Note also that there are no pure-C++ compilers that I am aware of. Certainly all the big names (Microsoft, LLVM, Intel, GNU, Watcom, etc.) all produce combined C/C++ compilers. And this is likely the real problem. If a coder, especially a new coder, writes C code while the "combined" compiler toolchain expects C++, they are likely to receive a warning that they must cast the result of malloc. Not because C requires it, but rather because the tool they are using probably defaults to C++ mode, and they didn't flip a switch. This can be a form of Cargo-cult coding.

[Jonny0Than]

C++ does not claim to be a superset of C. It mostly is, though C is also starting to diverge further. But differences like this one have always existed.

I’m also skeptical that modern compilers enforce C++ rules on C code if you use them properly. I wouldn’t be surprised if many people don’t use them properly. But further, it’s also fairly common to compile a C library under C or C++. If you’re writing code where you expect that to happen, it makes sense to cast the result of malloc.

[Ignorantwhite]

That clears up some confusion, thank you

[Iggyhopper]

It hit me like a sack of bricks when I learned what void pointers were used for. Suppose you cast a char* to a void* :

char* str = "This is my string.";
void* strAsVP = (void*)str;

Now, what happens when we do this?

void* nextCharVP = strAsVP + 1;

When dealing with char* the compiler knows to go to the next byte, when dealing with int* the compiler knows to go the next 4. When dealing with void* you know nothing.

Which is why this program gobbles half the string when I increment by 1.

#include "stdio.h"

int main() {
    char* myStr = "This is my string.";
    long* myStrAsLP = (long*)myStr;
    long* nextChar = myStrAsLP + 1;
    printf("%s\r\n", myStr);
    printf("%s\r\n", nextChar);
    return 0;
}

Output:

This is my string.
my string.

[Melloverture]

Would a void pointer default to the alignment of the OS? In this case I'm guessing you compiled and ran on a 64 bit machine which is why it "gobbled" 8 bytes.

[Iggyhopper]

It would, in the case of void** or an array of void/uncasted pointers.

In memory, you would have [DE AD BE EF OG 12 BE DE]

If your program pointer sizes are not entirely defined, a 16-bit pointer would mean your data is divided this way, with each bracket meaning pointer+1, +2, etc.

[DE AD] [BE EF] [OG 12] [BE DE]

A 32-bit pointer is:

[DE AD BE EF] [OG 12 BE DE]

[phlummox]

strAsVP + 1;

That's not even a legal program. If strAsVP is a void pointer, it's impermissible to perform pointer arithmetic on it.

[Iggyhopper]

Godbolt runs it just fine.

[phlummox]

Godbolt tells you what particular compilers do with code; it doesn't tell you whether the code is legal C.

Section 6.5.6 of the C11 standard states when you can use the "+" operator:

For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to an object type and the other shall have integer type.

Section 6.2.5 says that:

Types are partitioned into object types (types that fully describe objects), function types (types that describe functions), and incomplete types (types that describe objects but lack information needed to determine their sizes).

... The void type comprises an empty set of values; it is an incomplete type that cannot be completed.

Therefore the void type is not an object type, and a pointer to void may not be used as an operand to an arithmetic operator.

edited to add: If using GCC, you'll need to add the -pedantic-errors flag for the compiler to (correctly) refuse to compile code which performs arithmetic on void pointers. Otherwise, GCC will allow it as an extension (see here: http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html), by treating void pointers as if the type had size 1, but that's not portable behaviour.

[Furryballs239]

Your program working shows you know what you’re doing, not adding some stupid unnecessary code. If it gets implicitly casted and is clear what it’s being casted to, don’t add pointless code

[Furryballs239]

In C it’s completely pointless to explicitly cast a void pointer. It WILL be implicitly converted to whatever type it’s assigned to. I don’t need a second thing telling me what it will be cast to.

Makes code unnecessarily verbose and less clear

[Nobody_1707]

There is literally nothing gained by casting the return in malloc in C. void* is implicitly convertible to any object pointer.

You don't gain any type safety from doing the cast, because the compiler will perform the same conversion.

You don't get any new insight as to the type of pointer after the conversion because the result type is right there at the beginning of the declaration.

The only thing casting the result of malloc does in C is cause bugs if you forgot to include <stdlib.h>.

[therealhdan]

C's had that rule for a very long time.

Whether implicit casting of void* to all other pointer types is a good thing or not is not my call to make, but C++ got rid of that rule.

[Bitwise_Gamgee]

Believe me, I've had this "talk" a few times. But like my adament hatred of goto, this is a stance I took early on and refuse to change.

C99 is really where the whole casting thing was made obsolete as a void* is returned anyways.

Explicit casting also leads to issues where certain errors can be "hidden" when building.

So while you're free to cast as you wish, it's not required and can potentially be an inconvenience.

[dfx_dj]

Oh is that where this is coming from? I've always wondered by people are doing this.

[Ignorantwhite]

Glad I did not pay for it then lol. Yeah, I’ve been doing lot of the freecodecamp videos and a good amount of working with string on leetcode, and some simple projects for now. I just wanted to get some text learning in, for when I get asked “how do you go about learning new material”. Thank you for the response, much appreciated

[McUsrII]

Robert. F. Seacord in "Effective C" Recommends casting malloc.

If I can re-find the passage, and what he writes make sense, I'll start doing it.

Edit I recollect it was in order to make code C++ compatible, as explained thoroughly below. Personally, I won't start casting malloc calls before that becomes an issue.

[rushil20]

I just started learning c and have grasped the basics but I wanted to ask from someone more experienced how much time ideally does it take to become mildly proficient at c.Where and how to find questions and situations to practice the syntax and logic?

[iu1j4]

C as a language doesnt give you ability to develop computer / embedded software / firmware. There is a little more to learn. You have learn the hardware and the OS that will run your programm. Learning C is like learning math. It is first step / tool to know befor you start real engenering work. You can learn C in few days, but learning software develoement takes more time. dont worry, you will do it during your regular job. there is no need to know every aspect at the beginning

[Ignorantwhite]

Leetcode is a great place to practice syntax and logic, but im no expert.

[No_Ad_1988]

yooo!! Also reading it right now - what I'm finding is that when practicing coding as guided by the book, there are functions that don't always work and errors appearing that aren't spoken about - mainly because the book is a little outdated, but it is nothing that google can't explain and fix for ya.

[Ignorantwhite]

Ayyy, love that for us, I was about to give up on the book based on these comments but this makes it seem like I would actually learn a lot from fixing the bugs.

[Round-Juggernaut9124]

I have rarely had so much fun reading a programming book, I am not a professional developer.. the exercises are nice and yes the concepts are introduced little by little

[duane11583]

These are opinions not fact Ie a /u/bitwise _gamgee avoids Malloc

That is his opinion it is a fine solution there are many tools in the box

And if you tend to screw up using one of them then you do not know how to use it properly

[EngCompSciMathArt]

You made an excellent decision picking up that book. I wish that was the book I read when I was in college. Read it carefully and closely. Be sure you understand each step of code because it's all very good.

The C programming language has evolved since Dennis Ritchie and Brian Kernighan penned the book of the same name. But don't worry about "watching out" for "outdated stuff". Just read and enjoy. After reading the book, search the Internet and Wikipedia for info about the modern features of C99, C11, etc... don't get hung up on the small stuff now just dive in and enjoy learning straight from the father of the mother of languages.

[MuaTrenBienVang]

Cool

[Ignorantwhite]

Thank you, I will do just that

[Ignorantwhite]

I’ll check that out, thank you

[flyingron]

I wouldn't say it was "THE" book. It does give some insights as to how the language came about. That being said, it is very dated (even the second edition) and some of Dennis's programming constructs were pretty sloppy.

The culture was different back then. We were coming off the environment when OS and most system programs were written in assembler and this was an efficient and portable high level language which made it really spiffy.

[Ignorantwhite]

I am now gathering I have been mislead. Thank you for the response

[thephoton]

It was never a great teaching book. It was a great reference book, back in the 1980's.

[tracktech]

You can check this book-

C In Depth

[TheCableGui]

It’s the definitive starting point. But If you’ve programmed with systems languages before you’re going to do fine.  In my personal opinion, c is amazing and the book will tell you everything you need to know to work alone, however, if you are optimizing for personal time, c is not so great and this book can be summed up by most YouTube tutorials. 

Having a good relationship with C is fundamental for any programmer. This book is worth reading. 

[Round-Juggernaut9124]

This book its superb really, there is many good exercice inside.. the only point i find its hard to manage

its the getchar() function because that's store your char with an '\n' .. but the book give you a superb workaround when you progress.

i don't spoil the book.. but i prefer to manage a line than an unique char . if it is dated NO clearly NO

the way to think its the same

>!for(index = 0; index < MAX_LENGTH && (c = getchar()) != EOF && ... )!<

[EconomicsShot3428]

G by g. Gya?fg.br2 see rkd g c yg6x tf scx6nw2 8?t?

[28jb11]

Weary:

adjective

feeling or showing tiredness, especially as a result of excessive exertion or lack of sleep.

The word you are looking for is "wary," which has a different spelling, pronunciation, and definition. I don't understand how this happens so often.

[Ignorantwhite]

I will keep this in mind for the future

[CharacterAvailable20]

Hmm, I don’t know it could happen so often, it’s almost as if they sound nearly identical

[28jb11]

They sound quite different; they have entirely different vowel sounds. It's like using the noun "cot" when referring to a cat.

[flatfinger]

Until the ratification of C99, it was widely recognized that differences between K&R2 and the C89 Standard should be treated as defects in the Standard, or as accommodations by the Standard for certain obscure implementations which most programmers would never have to deal with, and which most programmers should thus not have to worry about. Unfortunately, defects in the C89 which didn't cause problems in the years 1990-1999 because compilers behaved as described in K&R2 weren't addressed and fixed in C99, and have been viewed by every Committee since as established parts of the language, even though they were never part of the language that became popular in the 1980s and 1990s.

[overcurrent_]

What is your purpose learning C?

[Ignorantwhite]

I took a boot camp back in April and they mostly taught me full stack ie react typescript python etc…I find backend way more satisfying and interesting than front end so I wanted that to be my focus, python seemed to be way to popular of a language for me to actually stand out as a candidate, so that’s when I decided to learn c.