161–170 of 189 posts
Earlier quoted context omitted.
"format not a string literal" is one warning I always upgrade to an error. Dear reader: you should do this, too!
Thanks! This prompted me to look up the flag to enable this. For GCC it’s: -Werror=format-security
Earlier quoted context omitted.
Why are these not compiler errors by default? Opting in to such important safety features seems like broken design.
One reason is locale-dependent format strings which are loaded from resource files. Also, in personal projects, I almost always used custom wrapper functions for printf/fprintf/sprintf for various reasons, so that default wouldn’t be of much use, unless maybe I could enable it for the custom functions.
Earlier quoted context omitted.
One reason is locale-dependent format strings which are loaded from resource files. Also, in personal projects, I almost always used custom wrapper functions for printf/fprintf/sprintf for various reasons, so that default wouldn’t be of much use, unless maybe I could enable it for the custom functions.
> One reason is locale-dependent format strings which are loaded from resource files. Aren't those usually resolved to string literals by preprocessor such that the compiler still could emit a warning?
> volatile type qualifier > This qualifier tells the compiler that a variable may be accessed by other means than the current code (e.g. by code run in another thread or it's MMIO device), thus to not optimize away reads and writes to this resource. It's dangerous to mention cross-thread data access as a use case for volatile. In standard C, modifying any non-atomic value on one thread, while accessing it on another…
These days it can be chained with _Atomic to achieve the desired effect. That said, oftentimes you need more serious synchronization mechanisms your library would provide.
Earlier quoted context omitted.
Strictly speaking there are essentially no programming languages that are even theoretically Turing-complete because they can only address a bounded amount of memory. For example, in C `sizeof(void*)` must be a well-defined, finite integer. But that definition is not useful in practical use.
There are plenty of Turing complete languages. For example JavaScript is Turing complete.
Earlier quoted context omitted.
Professional C developers definitely should be using at least designated init and FAM, standard features both added in C99 and currently 24 years old.
Well, it’s either a lesser known trick or it’s something people should be using. In general using lesser known tricks it’s not a good idea for production code. But I understand there are cases where there is no good alternative, so it’s warranted.
> There are some tricks, quirks and features (some quite fundamental to the language!)
Earlier quoted context omitted.
There are plenty of Turing complete languages. For example JavaScript is Turing complete.
Even if that was true, any definition of Turing completeness that includes JavaScript and excludes C is worse than useless in practice. It's useless for communication, it's useless for education, it's useless for reasoning about capabilities. There's simply no place for such a definition in a civilized society.
Earlier quoted context omitted.
> you can't change the order of the formatted arguments. You can with the $ syntax. Never seen it used though. Maybe it isn't very portable.
It is specified by POSIX, but not by ISO C (or C++). So most Unix(-like) systems support it. But the printf in Microsoft's C runtime doesn't. However, Microsoft does define an alternative printf function which does, printf_p, so `#define printf printf_p` will get past that. I think the real reason you rarely see it, is it is only used with internationalisation–the idea being if you translate the format string, the tr…
I like printf format strings, but as a way of handling localizable strings I don't think they are the best.
Earlier quoted context omitted.
The unary complement operator should get you there: unsigned int x = 0; const unsigned int max = ~x; while (x Or, #include const unsigned int max = UINT_MAX;
This is equivalent to while (1) { calc(x++); } which is an infinite loop, since the expression x is always true
Compound Literals in C are great. They're no surprise to anyone coming from more sophisticated languages, but I've never seen them used in the C codebases I've worked on. What with C also allowing structures as return values, another rarely-used feature, they're really useful for allowing a richer API than the historical `int foo(...)` that so many people are used to seeing. C has so much legacy that it's really hard…
I remember working on a commercial project in the mid-2000's that still had #ifdefs for K&R C prototypes (meaning, pre-ANSI C.) This was a recent-ish project at the time, started in 2000. Were people going to go back in time and compile it on an old architecture? I doubt it.
C moves slow.