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!"

Follow me on Twitter: @davepl1968

Primary Equipment (Amazon Affiliate Links):

[DavesGarage]

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!"

[mathewbenson]

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

[CapnSlipp]

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.

[uzimonkey]

_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.

[mcg]

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.

[turdwarbler]

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

[ikouzaki]

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

[HaydenLikeHey]

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

[hofertyp]

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!

[modolief]

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.

[tomysshadow]

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.

[landonkryger]

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.

[jope]

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.

[technowey]

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.

[grahamheath]

Useful;
Reminds me of a problem. Many years ago when when the UNIX time (number of seconds since the epoch) went from to
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.

[skiera]

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

[WolvericCatkin]

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.

[nickwallette]

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.

[richardgg]

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.

[mathewbenson]

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