Stupid C Tricks: Unsafe Functions You MUST Avoid! 

My apologies for the erroneous prototypes that indicate a return value: I stripped the return values at the last minute to simplify things, but didn't change the prototypes, proving there's "no such thing as a trivial last minute change!"

An alternative fix for strcat_exampleC2() is to just (always) set the last character to null- szStrOut[MAX_PATH-1] = '\0’; It doesn’t matter if the string ends up being shorter; all string functions stop reading when they hit null, and setting the final character unconditionally means no branching and thus produces simple fast assembly.

Your first two functions have a size_t return type, but there is no return call.

_countof is not new to C because it's not in C at all. It's a Microsoft macro buried in one of their headers. Probably still best to use sizeof(x) / sizeof(x[0]) or since we know these are char arrays, just sizeof(x). Edit: Further, I don't think any of the _s functions are available on glibc. They're in C11, but in the optional annex k which they never implemented. I don't know why, but at least on my recent GCC/glibc installation they're not present.

snprintf will not overflow the buffer and it will add null termination, so it is safe. The thing to be aware of is that it returns the number of characters it would have written (excluding null terminator) if the buffer would have been large enough. That way you can check if the resulting string was truncated due to the buffer being too small.

first example also had another bug, it says it returns a size_t but there is no return statement !!!

Amazing vid. Very educational! I'd love more of this. Thanks for dishing out such high quality content.

As a relatively new C programmer, I find stuff like this really helpful and fascinating! Thanks for this, Dave!

I remember the early 00 years sitting in programming class and my teacher just throwing that red/white kerninghan and Ritchie C book -> still to this day pointers and functions with pointers extremely scares me. Somehow I'm glad that I've started with C. It takes you much much longer but because it's more leaned towards hardware you learn so much more important background basics that let's you better understand how the software integrates with the hardware!

Great instructive video, perfect for my needs: I'm teaching computer science to a budding software engineer and C is one of the languages I'm teaching him. I always remembered string handling in C as difficult, and am glad to have an update on the proper methodologies for doing this important task.

Visual Studio won't even let you use most of these anymore without setting a specific flag. Which is a good thing, it's certainly saved people from making these mistakes.

I've recently been doing a ton of of string printf upgrades at work. Instead of sprintf or it's variantes, I've been using std::format and love it. It does require you to be using c++20 though.

Could you clarify the issue with snprintf? You say "the size specifier is generally based on the format specifiers", which is also true with sprintf_s. If you don't have a big enough buffer, snprintf will truncate, put a null terminator, and return how many bytes it would have written if the buffer was big enough (excluding the null terminator). sprintf_s and snprintf_s do the same but sprintf_s returns how many bytes it actually wrote, and snprintf_s returns how many it would have written, same as snprintf. In all three you need to check the return value to know if the string was truncated or not, but in terms of not going off bounds and returning a null terminated string they all seem equally safe.

On the STRTOK part: - tried both C and C++ ways and STRTOK was maybe 90% faster than using stringstream in c++ when parsing very large text files in loop.

This reminds me why I code almost exclusively on Linux. I really would like to learn how to write Windows programs (and I’m into retro computing, so that would be C/C++ 7.0 on Win 3.0 to VS 2000-whatever on Win 7), but I am completely lost on the quagmire of string handling and file IO calls with different char sizes, and having everything abstracted behind cryptic type definitions. I’ve tried learning this a few times, and it seems like every example says “don’t use all the other ones, just do this ...” and then directly contradicts the last one I read. It just feels like there’s standard ANSI C, and there’s ... whatever the 🌮 is going on in any given Windows source code example.

This was a good video. I'd forgotten, if I ever knew, that strcpy_s always added a null terminator. The bugs are very obvious to an experienced C programmer. The C++ function had a bug too. The return type was size_t, however, the function didn't return a value.

Correction: `endl` isn't just the newline character, the standard specifically specifies it should explicitly _flush_ the relevant buffer, which in the best case, is a no-op, given most buffers are designed to flush on newlines, but at worst, can be introducing unnecessary overhead if the flush is poorly implemented.

Useful; Reminds me of a problem. Many years ago when when the UNIX time (number of seconds since the epoch) went from 999..... to 1000..... i.e. ASCII length increased by 1. An application that used this to generate a file name suddenly started misbehaving. As a UK support group we worked out what was happening. The only difficulty was convincing the code writer that somebody without an american accent knew what was wrong with his code.

I would love to watch more videos about C/C++ code by you!

another problem with the first example is, that a non-void return type is declared but no value is returned. If any caller function attempted to use said return value it could lead to undefined behavior

I was a C and C++ dev back in the late 90's, self taught. After that, I told myself I would not have use of my skills because C/C++ in general is not used for developing business solutions, instead it's used for some background scrubbing of bytes and data, but definitely not a full business solution (not without a significant amount of time and effort, that is). So I turned to IT infrastructure. I haven't touched programming through all those years. This video makes me wonder why did I stop, it was all too natural to me. Thanks for the video, Dave. Perhaps you reignited something which I love.

These should be basics when starting out with C.

OG strtok also has another flaw that makes it unsafe for threaded applications: it uses a static variable to keep track of where it finished off the previous call so that it knows where to start on the next.

This video seems to have an incorrect description of strtok and strtok_s. The strtok_exampleC1 is actually totally fine (aside from not being multithread-safe). In the video, he says "The problem here is that it's partying[?] on your memory and you have no idea how big your memory is." This seems to be contradicted a couple of sentences later where he implies (accurately) that strtok just modifies the input string: "So by using strtok_s, we can do it safely. Rather than modifying the string in place, it provides you with another value, rest, which is where the rest of the string can be found". This contradicts what he says earlier about strtok "partying on your memory". No, it replaces any occurrences of characters from the delimiter string in the input string with null terminators and returns a pointer to the current token (see the man page). As long as the input string is null terminated (i.e. a valid C string), it's totally safe for single-threaded use. The issue with strtok is that it stores a pointer to the input string in a static variable (which is why on subsequent calls you pass a NULL pointer as the input string parameter so that it knows to continue tokenizing the same string) which isn't threadsafe. You need to use the reentrant version, strtok_r, to be threadsafe (again, see the man page). According to my quick scan of the MSDN page on strtok_s, it appears that it is the Microsoft equivalent of the POSIX strtok_r (or roughly so). Both functions use a third parameter as an input/output to store a context for tokenizing an input string instead of a static variable. Passing NULL in the first parameter indicates that it should continue tokenizing from the context pointer. This is totally threadsafe. The incorrect understanding of strtok in the video is evidenced by the name of the variable passed in as the second argument to strtok: "tok". That should be "delim" or something since it tells strtok which characters to use as delimiters, it doesn't output the next token there or anything.

Make more 'spot the bugs'. I love these. I use my own as interview questions.

Loved the exaples for both plain C and C++, showing how much easier those basic things are now.

Much appreciated. On a hobby level I have dabbled with Objective C, C and C++ and Swift, and of course have had some issues. Right now deep into an Arduino project and good to be reminded of how to think and to write safe code. And for me as a hobbyist, some tools and languages are easier and safer than others

Since you’re only printing the concatenated strings anyway, you don’t need the output buffer, or any string copy or append functions. Just puts the first string, then puts(“ “), then puts the second string.

These safer versions of the standard functions are unfortunately only implemented in MSVC and not in for example glibc. This makes code using these functions not very portable.

I learned something new!. Please make more of these videos!!. Thanks, Dave!

Fantastic video. Please, please, please, start a course of C/C++. The way you explain is gold, showing each step, explaining without making us feel like babies. I cant have enought of this. At least, please make more of this kind of video explaining things. Love ya

size_t type function has no return. You didn't check buffer lengths. You trusted the input to actually have the zero on the end.

There's also asprintf, which I think isn't part of any standard yet but is still available most places. It allocates a buffer just long enough and returns a pointer to it which you do have to free later, but you don't have to choose between wasting a bunch of memory every single time or risking some of your strings getting truncated.

Thanks much for this. One day all these depreciated error makers will be pulled from the libraries (not). Of course you assumed your input strings are null terminated even if larger than expected, however they can also overflow outside your memory space even while being read if they are not. Love to see an episode on string input verification.

Dave, thank you, asa newb to C and programming in general this was very very very useful information !!!! thank you for these videos !!!

char s2[N+1]; strncpy(s2, s, N)[N] = '\0'; does the job very well. No new function required. BTW: there is a reason why the good ol' strncpy does not add the '\0'-byte if all available space is filled.

Great video. Oh well I will stay in the safe waters of C# for a while longer.

I often ended up writing some of these kinds of functions myself so I can do it the way I want from the start. I also hate how using string functions ends up with a lot of redundant calls to strlen. So I’ll often just do the strlen once and write everything else using more generic functions like memcpy

This is a very strong argument against writing programs in C now that alternatives exist.

Correction: lstrcpynA&W will always zero terminate the string correctly.

Thank you! This answered a lot of questions I've had about the number of string function versions.

Thanks for reminding me why I don't do C any more if I can help it!

C is a fine language, sadly too many of us haven't had proper training with it which is what gives C the reputation to be a bit dangerous (software-security wise). In my case the university also is to blame, in my opinion. Why does programming get teated like any subject while it is an art. You can't become a skilled programmer in just 8/12/20 weeks, however long a period lasts at a university, teaching programming should be done in a different way than for example teachint physics or chemistry, it should be taught by being a red thread throughout the curriculum, not so much by giving assignments and not giving any feedback but by giving pointers, checking what the student has done, then explaining what a better approach would have been...You shouldn't get graded on it with an exam, you should get continued feedback. The major point is that programming iis an art and a skiill, not so much about reproducing knowledge.

the only 2 bugs in original function are: -function is size_t but there is no return -while explaining the function you didn't specify the 260 chars limitation, it should be in the docs or comment near the function MAX_PATH is used specifically for working with path in windows which is also limited, so if you somehow exceed it, your program is not going to work even with larger buffer. p.s. there is some fancy way to remove this 260 limitation, but no one does it except microsoft because 260 is always enough

As someone who has only dabbled in C programming at a very basic level. I enjoyed this video.

When I first learned printf I was astounded at the idea of a function with absolutely no type safety, and then more astounded that I seemed to be the only person bothered by it.

Some of my earliest efforts at programming involved C programs in DOS. DOS had no memory protection at all. Any program could access any address in memory (the whole 1mb). If you somehow messed up the null termination and then output a string, you would get some interesting results, as in, a bunch of binary garbage on the screen, usually with "MICROSOFT CORPORATION" fairly early in the garbage. Apparently that string was stored somewhere pretty close to the heap.

Note that sane implementations of snprintf() is guaranteeing a zero-terminated string as long as buf is at least one character large. So same as sprintf_s(). The difference is sprintf_s() will issue an error and result in an empty string if the formatting string is invalid.

_countof is a macro that is defined in VC but not e.g. GCC. It will also give erroneous results when given a pointer. That is, char buf[64]; char *p = buf; _countof(buf); // will return something sensible _countof(p); // will not, as then the sizeof() will return the size of a pointer, instead of the number of elements in the array. Another gotcha worth pointing out.

Great video as always. Would be cool to see more advanced C++ techniques.

So much truth in that. I inherited an old codebase which probably started off as a quick hack and from that point. And now time and time again I keep finding similar bugs. Sometimes they do bite, sometimes using various code checkers, sometimes by inspection.

I learned C years ago using Borland's Turbo C 2.0. It seems that I have to forget all that and learn the proper, modern way to program in C/C++.

I wish I had you for my CS prof.

I like these educational videos a lot more than the bells and whistles of others. The speaking speed too is easier to understand. The code is concise and gave me aha moments. Now the challenge is to use it because the _s suffix is awkward.

Last Crusade would've had a completely different ending if they had Indy choosing the correct C string function instead of the holy grail.

"Stupid C Tricks" But they are the essence of C. 😁

strncpy is for writing to fixed length, nul padded, but non-NUL terminated string fields in structs. It really shouldn't have str in the name. The _s functions are Microsoft specific extensions that somehow got standardised under pressure for ms, but no Unix devs use them nor Unix oses support them. And strlcpy and strlcat are fine and serve the same purpose as the _s versions. Anyhow fixed size string buffers should be a thing of the past and user provided strings should be dynamically allocated.

Did most programming with Pascal. Later Object Pascal. But also some other languages. These unsafe string problems were only in C and some C++

using a buffer with a maximum size is not correct. you can make it “safe” but not correct. you should first calculate the size of the output buffer and then you don’t even need the safe functions because you know the output buffer is big enough

I hope this is the start of a new playlist called "Stupid C Tricks", because I am looking forward to more videos like this.

One thing to note is that strcpy_s and strcat_s are windows only and will likely not work on Linux and glibc. Cross platform and backwards compatibility is the reason why you don't see those functions used anywhere.

2:28 No need to create the complete string. Substrings and space can be sent to cout in sequence

For all functions: check the return value. Most report errors there, even printf. Only if you have no way of handling them (like an error to fprinf(stderr, "...") during program exit), ignoring is all you can do.

Thanks for all these C tutorials and tricks!

Even worse with that first example with the strncat()s is that the "n" in strncat refers to the *source* string, not the destination. So strncat(szStrOut, szStr2, MAX_PATH-1) will still risk overflowing szStrOut.

I don't do coding except for personal interests, but if it were me (and what do I know, I am just some dude on the internet), I would pass a const string & into the function, construct a std::string_view front it, then use the find first of member function of the string_view class to find the token, use the substr function to pass the token to cout, and then use the remove prefix member function to move the front pointer in the string_view up to the postion after the delimiter. repeat until size or length = 0; Then we have to decide what to do with 0 length tokens, as there could be 2 delimiters in a row. The other assumption is that the string isn't destructed while the function is running.

Thank You @Dave they was excellent and I learn a lot from this. Can you make more videos like this please?, especially for C and C++. Thank you John Ireland

This is why I love C++

And that is a great example of why I don't use standard functions/libs in my (automotive) embedded software. They simply cannot be trusted...

The _s family of functions are nonportable because they're from Annex K, which the standard doesn't require, and in practice basically no platforms actually implement as defined.

I only ever used C in DOS. Also, I only had a free 16bit complier. The big challenge was trying to make a "game" which uses over 1MB of disk storage, while only using 64kb of ram and therefore a dynamic executable which would read procedure files and overwrite parts of the 64kb of ram. Most songs, which had to be interleaved with game code would take up 20kb of ram just to drive the PC speaker. If you didn't properly guess how long code took to execute the music would have halts in it. I don't know if I was doing things wrong or not as I was self taught and didn't use libraries. At least I could specify which memory addresses were overwritten to not overwrite DOS, TSRs and the core game code to overwrite itself in ram.

As someone that's being doing C++, web tech, Java and python the last 15 years, seeing these C stdlib functions gives me some PTSD. The C API was/is hideous.

I wonder how many of these unsafe behaviors were compromises in the face of the hardware they had available, or they just didn't see where it would go wrong? Which isn't necessarily a slight, when you're advancing the state of the art of something, you're going to miss at least a couple small details.

That book sounds interesting. Best of luck in your future!

After the first few tries I quickly learned to never ever trust standard str functions. I always write my own that goes character by character. Reverse, concat, split, per word reverse, lowercase, uppercase, shortening, extending, inserting, number conversion, whatever. Although I try to optimize them, I know it's slower than the std ones, but at least I trust my own functions.

Well the first two functions expects size_t returned .. but a value is never returned

First example: there final solution should be: char szStrOut[MAX_PATH + 1], also return statement from function ismissing.

String manipulation in C is one massive bug.

Bookmarking this for later. Thanks for the tips!

Counting sheep don't work for me, i'll use this tonight. Cheers.

Thank you! Please do more videos on "can you spot the bug" theme.

Its unbelievable how many programs over the past 40+ years were written the old way and were mostly fine except when hackers are injecting unexpected code. I picked up my first book K&R ANSI C at the tender young age of 11 and read it cover to cover, did every sample program in the book. Really back in the day if you were working on combining a last name and first name with a comma into a string from sanitized user inputs, everything is fine. Even on the database side, if your field lengths are set properly (and back then when we were using DBase and other ISAM databases you had storage constraints so you wouldn't just arbitrarily have 512 byte name fields), reading and using this data was fairly safe. It's really when these inputs are coming from unknown places like API calls, web calls, etc. and honestly programmers SHOULD have been checking length and not relying on assumptions. But I guess when people make a "protocol" and specify the maximum length of the incoming URL in a GET request, and developers assume that the third party is following those requirements, things get really dicey. One thing I've learned is - if there's some way to externally interact with something, you make sure everything is bulletproof. I used to get paid to figure out how to break existing embedded systems for a small company that made vending systems and guess what people in the field were doing to cheat systems. And found MANY ways people would HACK systems from cloning NFC cards and simultaneously loading/using points, to using static charge devices to short out electronics.

Yes, the misappropriate use of "inheritance" in "language design". In most cases, bad (or assumed) data definitions and abstractions in the evolution from Fortran to C and other derived or variant languages. In that sense, COBOL, with its explicit "Data Division", was always going to be a superior "language" mechanism.

I usually just let calloc fail and crash if it gets too big, because at that point, you've lost the plot anyway and your input is likely corrupt. Crashes are bad, but are better than corrupting memory.

2:33 disproving Linus Torvald's ridiculous claim that C++ hasn't fixed any of C's issues in a few seconds.

Good thing my code is only run by about 5 people!

Their conclusion: The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. More effective and less intrusive approaches have become commonplace and are often preferred by users and security experts alike. Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed.

Just saw a video couple weeks ago on how to use PowerPoint for those amazing code transitions, wasn't expecting to see it so soon .-.

*WOOOOOSH!* is the sound of this video going over my head! 🤣 But I don't know what it is, but I find your videos and voice calming, interesting, entertaining and educational! {:o:O:}

This video strengthened my motivation to learn Rust

To be fair that's not a very good use of C++ (copies, dynamic allocations etc.). In C++23 you would rather write something like this. It's simple, safe, cheap, does null checks, compile time parameter checks, accepts char*, strings, ranges and any other compatible containers, doesn't do dynamic allocations, doesn't overallocate on stack or have hidden implementation restrictions like MAX_PATH length. void example(string_view s1, string_view s2) { print("{} {}", s1, s2); }

Amazing video very informatic, thank you

Safe C feels like an oxymoron. I thought the whole point was the language being as safe as riding a rocket powered unicycle?

The safer a function, the slower it is. More safety checks and condition handling means more computing time spent. In my opinion, one should write their code in a way that makes it impossible (barring the inevitable bugs to be fixed) to overflow memory (like has been done since the beginning, right?), rather than relying on the standard library functions to do so. Also, GCC doesn't have these MS functions.

You can limit buffer on scanf function, just use max field width with the format

It's baffling that these functions have been rewritten dozens of times and yet were still unsafe.

To be fair, I haven't touched anything C since college, but in my over decade of programming I've never heard str pronounced "stir", it's always just fully expand it to "string". Which I guess if you watch to the end he does do this.

Then your colleague calls the function with the same pointer twice and demons come out of your nose!

7:09 I was a little confused when I saw you using the word 'token' in the place of the arguments which is meant for 'delimiters'. The way I understood the term 'token' is that it refers to the extracted characters (the chunk), not the separators. Did I miss something?

Did the authors of C, K&R, intentionally define unsafe functions for C in the 1970s? If so, why did they? Were they trying to make C a high level, "universal" assembly language?