"New" Features in C - Dan Saks 

Most vexing parse strikes again :P

😂

The Well Tempered Standard

Reviewing this again in JUune 2021.

Over what?

@@porky1118 Not C, presumably

@@porky1118 In my case I prefer it over C#, C++ & Rust, haven't seen any objective C as yet so no opinions on that, wouldn't be surprised if I still prefer normal C though, I also tend to stick to C89/C90 just to save myself some hassle if anyone decides to compile my code in it, can't complain about a problem that don't exist :)

Compound literals are almost done right, except for the fact that there's no way to declare them as static const, which should otherwise represent the most common use case.

@@flatfingertuning727 maybe not explicitly, but you can still use 'em that way in certain situations. E.g. outside of a function, you could do this: struct s { int a; int b; }; static const struct s *const VARNAME = &(struct s){ .a = 10, .b = 11, };

@@flatfingertuning727 c23 to the rescue!

@@ukyoize Better "Nate" than lever, I guess? The dialects supported by C compilers improved a lot between 1974 and 1999, but C99 only incorporated a few of the improvements, added some total garbage. Many more years have passed since C99 than between 1974 and 1999, but "design by committee-itis has stifled any useful evolution or fixes.

This is because C99 inline works differently from C++. You are supposed to explicitly instantiate inline function in one of .c files. This way linker is not required to understand "weak" symbols as there is no duplication. You just need to put an extern declaration in one of files with inline definition visible. Confusing way to do so and I hate it tbh.

alloca isn't standard, and has most of the same drawbacks as VLAs, most notably overflowing the stack if you don't check if the size is below some safe maximum, and if you are checking that, there's little reason to not always allocate that maximum size on the stack with a completely ordinary array.

@@Zeturic Mostly comes up in embedded systems where the stack and heap are just slices of the same global address starting at opposite ends. If you use the heap, you have to deal with fragementation yourself, and have to worry about the stack and heap growing into each other.

@@lperkins2 The "hope for the best" semantics you describe may be convenient, but make it impsosible to really know whether an application will work reliably. Better is to have a fixed-sized stack, but try to minimize its usage, and then carve storage for other objects out of whatever space remains.

@@flatfingertuning727 What "Hope for the best" strategy am I suggesting? If you have all your necessary data stored end-to-end in a large block of memory, and it doesn't fit, how you lay that out doesn't matter. If that is not the case, putting all *dynamic* data on the stack is the most efficient general memory layout, as it neatly avoids fragmentation. Keep in mind some platforms don't even *have* malloc out of the box, because you *really* don't want to use the heap when you're in the

Exactly, I wish they standardized alloca() which is supported by every compiler anyway, instead of inventing a new syntax.

What's the purpose of having such wide pointers in that context?

@@AJMansfield1 The answer is complicated. There is actually only 64 bits of machine address tucked inside the 128 bits. IBM i uses a 'single level store' model where permanent storage is allocated and referenced by virtual address. Most systems have a file system with directories and paths built on top of disk storage. IBM i uses addresses (the same type of address used by the CPU) to identify storage just above the disk layer. These addresses are persistent-- when you allocate storage and get an address for it, that address can be used indefinitely across reboots, OS upgrades and in some cases even across machines. To make all this work and provide security, the pointer is encapsulated in a larger 128 bit pointer. This provides some type information (pointers can be to simple data items, to functions, to invocation stack frames or to encapsulated objects-- each of these is a different type.) There is also a 'tag' bit associated with every 128 bits of storage. If the tag is not set, the 128 bits is simply not a pointer. User programs can't manufacturer pointers like you can on other systems because they don't have instructions to set the tag bit, other than in appropriate ways (such as incrementing a pointer within bounds) Aren't you glad you asked?

@@johnvriezen4696 Thanks, that's really interesting.

And what is the type of the difference of 2 pointers?

@@tatoute1 The type of ptrdiff_t in C is 'int' so 32 bit signed. However, if you take int i = p-q; where p and q are addresses from different segments (e.g. one address of stack data and one heap location) and then add i to q, you will not get p, you'll get NULL. (this follows the C standard as taking the difference of pointers to addresses that are not to the same struct or array results undefined behavior.)

It's because of that stupid bracket placing ...

It does say at the bottom of that slide that it’s easy to get wrong 😂

I haven't experienced it, I'm still pretty new in embedded programming, but, I have read that some machine hardware has defined size of bytes being larger or smaller than 8 bits

I think it’s the same in C++, but at least in C, the type `char` is exactly one byte big and CHAR_BIT (which thus is the size of a byte) is at least 8.

It is, a byte refers to the smallest addressable memory block, and there is hardware, especially older hardware with other sizes than 8 bits. More info: en.wikipedia.org/wiki/Byte

@@humm535 A char doesn't have to be 8 bits e.g. if the hardware only supports 7 bit ascii Edit: You're right, it's at least 8 bits

@@bene5431 Yes, a char does have to be at least 8 bits wide. If you don’t trust me, take a look at 5.2.4.2.1 _Characteristics of integer types _*__*

Bring more pain to the maintenance devs huh ?

I mean that's great but you end up having an additional pointer in the stack for every array you'll be manipulating, plus it prevents you from using restrict optimizations, usually my go-to solution is to use macros for indexing

To be honest, your best bet is probably to just email him. It looks like he might sell training, so he may not give them to you for intellectual property reasons.

I have seen restrict used as an identifier in pre-C99 code to cite one example

@@nathanrcoe1132 this sounds very plausible. Do you remember anything else about it? Was it used as an identifier or a macro of some sort? Was it easy to cleanup? Was it worth porting to C99?

@@yoloswaggins2161 I think it was just an identifier, and I don't think the code has been updated for the new standard because some platforms were not worth trying to get a conformant compiler for.

@@nathanrcoe1132 Alright well thanks for sharing. I didn't really consider it until you pointed it out then it seemed like the most obvious thing in the world.

If you re-declare an identifier, the compiler will give you an error, but in the case of variable shadowing, you'll get a warning at most, because it's allowed. Local variables typically don't have a library or other name as a prefix and may unintentionally mask global variables.

C in a Nutshell (the 2015 edition) , is up to date with C2011.

Modern C

Then you'd be assuming that the newer standard, which by definition you don't know about when you're writing this code, is completely backwards-compatible with the existing one. Maybe you'd still do it if you were willing to live slightly dangerously, or maybe you'd output a warning if the version was greater (not equal). The safest practice would be to force a compilation failure if the compiler is targeting a newer standard than what you had in mind when writing your code, thereby forcing the person doing the compiling to either explicitly target the older standard or wait for you to patch your code to support the new standard.

@@Adamantium9001 It should still be checked for, or the code will assume it's C90

Since everything in an enum needs to be known at compile time, this allows the user to set the size of the arrays there, which is needed at compile time. It is the same as #define. This enum trick can be used to calculate n! for example at compile time using recursion.

AFAICT it's basically to prevent the compiler from yelling at you about making a variable length array. The members of an enum are all const.

I wouldn't suggest using #defines... Text substitution is bound to break sometime. His two tokens ('m' and 'n') are const integer types local to the scope of their declaration. void test( void ) { { enum { foo = 3, bar = 7 }; printf( "%d %d ", foo, bar ); } // okay printf( "%d %d ", foo, bar ); // compile error: foo & bar unknown } Why he used two 'enum' statements is unknown. If C programmers can't reliably free alloc'd memory, can they be expected to #undef tokens after use??

Volatile does not influence caching, nor prevent reordering by the CPU at runtime (it does not imply a memory fence of any type), it only prevents the compiler from doing certain optimizations at compile time.

@@ixp_ninja Maybe.. For memory fencing, cache, and whatnot, sure, I'm with you,. For memory access order, I am not THAT sure... but mostly if you read say twice from the same location in C (as seen symbolically) it will definitely instruct the processor to actually perform the fetch twice. If fetching just one byte, it will perform a single byte fetch, not a word fetch for example. If for example reading from a location has no side effect, say : void foo(char * volatile c) { char a; a=c|0]; a=c[1]; return; } without the "volatile" this *MAY* result in returning to caller without doing anything. With 'volatile' both single character reads *WILL* be performed in THAT order - at least the generated code will instruct the CPU to do so (Whatever the CPU reorders or not is beyond the scope of the language).

@@ivanscottw for this example I agree, but strictly speaking the compiler (and CPU) is still free to reorder operations around volatile storage (see e.g. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-w3_e9vZj7D8.html), it just isn't allowed to remove the accesses completely, or reorder in a way that changes the side effects.

You mean sizeof(d[0]) ... "data" is a type (sigh) :-(

@@robegatt Well, as long as sizeof(d) == sizeof(packet) == sizeof(d[0]), then you can use sizeof(data), and so what data is a data type? You can use sizeof on a data type or a variable. When you use sizeof on a variable, C infers the type. On a 64-bit data type, sizeof(long) = 8 bytes, sizeof(int) = 4 bytes, etc. However, normally, I use ... assert(sizeof(d) == sizeof(packet)); packet *p = malloc(sizeof(packet) + (n - 1) * sizeof(d[0])); // Replaced sizeof(data) with size(d[0]), but keep in mind that both work.

@@BruceBigby You wrote sizeof(data[0])... you cannot subscript a datatype.

@@robegatt Oh, yeah. You're correct. I'll make the correction. I looked at the original code in the video and presumed that he was using a variable, rather than the data type.

@@BruceBigby yes that what my "sigh" was aimed to. Calling a type with the identifier "data" is not the happiest of choices.... besides I tried and my compiler didn't complain but returned 0 as the size. Very nasty bug if it was some real code. You are right that you can take a sizeof() a type, that is basic stuff.

In the video

@@nickkotte9899 Hahaha

@@nickkotte9899 Actually, if you watch the video, you can see that the presentation gets cut short. He really only covers changes in C99. The C11 and C18 content isn't there, hence the need for the slides.

github.com/ACCUConf/PDFs_2015/blob/master/Dan_Saks_-_New_Features_in_C.pdf Here? It's from 2015 but I guess it's the same

with static inline, when a non-inline version is required, it becomes a static function in every compilation unit which needs it.

@Tintin what amazes me is that there are vulnerabilities in presentation slides from people that are supposed "to teach" us the language. If so, what can we expect from just a regular dev?

@hammertapping do you upvote your own comments?

@hammertapping jesus, dude, you need to relax. And maybe learn C syntax as well.

@hammertapping Machine formatting (a la clang_format) helps with this kind of bug. This is a cast where the indenting is misleading.

I love that the next point is "this is easy to get wrong." It seems so!

I have to agree with your last acronym. C89/c90 is so last century. I fail to understand why folks can't embrace these changes, the new sized types and corresponding #include macros for printf/scanf are a godsend for portability. And as Dan pointed out the designated initializers are a great way to make the code more comprehensible.

The only way to access the “bit” data is to just use code like: char thing=25; thing

Try to search for 'bit fields'. Maybe it could satisfy you requirement for bit manipulations. Remark Even forced alignment can be done by using size zero.

By definition, a "byte" is the smallest addressable unit. If you want a "bit" type, you either waste a whole intfast_t storing one bit to make things as quick as possible, or you waste time packing and unpacking bits from some kind of packed scheme. It's easy enough to roll your own if you need it and it will probably better suit your application than a standard implementation.

@@tissuepaper9962 IMHO, maybe it theory, but in practise you are not completely right. There are processor architectures, where the smallest adressable type is a "bit" type. For example Intel '51 and its bit adressable memory (addr range starts at 0x20, just after register banks). Even some ARM chips are able to do bit adressing (Cortex-M cores) - see so called 'bit banding' for more information. And last but not least, in general your information about "wasting time" is definitely not true. (You can look into instruction timing table for I'51, if you need facts.)

@@jardahybner9227 you're not understanding me. The C Standard *defines* a "byte" as the smallest addressable unit. It doesn't matter what size it is, there are systems that use 1-bit bytes.

That's the kind of thing that we're doing with the C+ Project, except that we're pulling features from C++ because of the abundance of readily available C++ compilers and the propensity of legacy C code to migrate to C++.

@@maxabramson4781 but C++ is terrible. If I wanted C++, I would've just used C++. The point is make C better and just as good as C++ without making it C++.

@@G33KN3rd Okay, but the whole idea of the C+ Project is that we need the code to compile now while we're working on the standard. Hoping that it will work doesn't allow for testing, debugging, and benchmarking.

@@maxabramson4781 àa

Well, people have been saying this for decades, yet C and C++ stick around.

What if `n` is zero?

Missed casting the rvalue to a 'packet' pointer, didn't he...🤣

Casting results of malloc is not needed. Since malloc returns a void *, It can be assigned to any pointer variable. @@rustycherkas8229

Brian Kernighan addressed this decades ago in a paper _Why Pascal is Not My Favorite Programming Language_. Using a decent search engine you should be able to find a copy.

Thanks for the cite. Good article. @@BrianHaug

Yes, C as it is is simple, clear, standard and clean... Hope C People will never do as the People of "serial updates ++" do ...

They're the reason why I prefer C. I don't like the absolute mess they cause.

There is _Generic selection in C11 now.

Lambas are useless, just make another function

Just use C++ then lol

As the old joke goes, C has the IOCCC (International Obfuscated C Code Contest). There is no C++ equivalent, C++ has templates.

@@adrianliung8374 Didn't it leave uncovered everything related to threading that was introduced in C11?

@@defeqel6537 Yeah, he did focus a lot on C99. I would have liked to have heard more about C11 as well.

@@defeqel6537 The C11 threads API is optional and most standard libraries, including glibc, don't support it. Even worse, most don't even set the __STDC_NO_THREADS__ macro, despite that making the implementation non-conforming. So it's no surprise he doesn't mention it. Edit: obviously the macro name uses double underscore on each side, but I don't think youtube has an escape character for italics.

The tool has been used the wrong way. And taught how to be used in the most counter productive manner ever. "Education" like usual.

C90/C99/C11 *are* new languages, they just happen to share a lot with ANSI C. And the features mostly are there to simplify and eliminate boilerplate code for things the compiler can do for you. The less code you have to write (and the less code that is there just to jump through compiler hoops rather than express the algorithm) then the less defects that code will have.

@@JamesChurchill See text in bold at 2:54 . They are not new languages. They are new versions of the same language with strong retro-compatibility requirement. Any code that was compliant with any previous version of the standard MUST work as initially intended when compiled under the new version. C99 has all the pitfalls of C90 plus its own ones. C11 has all the pitfalls of C90 and C99 plus all its own ones. And so on for future versions of the standard. All those updates on the standard can only patch a few cosmetic things but they can't solve core problems. The best illustration is at 52:50 . The standard failed to enforce VLA, which is a major progress to reduce memory leaks, as a required feature in C99 compilers and had admit that failure publicly by falling back to optional in C11.

@@JamesChurchill No, they're not new languages as the newer versions have to be backwards compatible. They are improvements on the same language. If they were new, they wouldn't need to be backwards compatible and C99 would have "bool" rather than "_Bool" for example.

@@JamesChurchill D is a new language which has a version called "D as a better C"

@@NeilRoy Whether they are backward compatible depends upon whether one views constructs which were defined in C89 but not in later versions as invitations to deviate from the old behavior *in cases where the new behavior would still meet programmer requirements*, or as deprecating any reliance upon the old behavior. If, for example, it would be acceptable for a program to either hang or produce meaningless outputs when fed invalid inputs, under C89 one could simply write a loop which would terminate when given valid inputs, and might not terminate when given invalid inputs, without having to include dummy side effects. If C11 had added a rule that would allow compilers to *cleanly* defer the execution of loops until the first observation of any side effects therefrom, or omit loops entirely if no such observation ever occurred, that would allow useful optmizations in cases where code never ends up using any values computed within a loop that might or might terminate. What C11 actually did, however, was to allow implementations to behave in completely arbitrary ways, which may include arbitrary memory corruption, if a program receives inputs that would cause execution to get stuck in a side-effect free loop. The net effect is that the only way to ensure that programs behave in tolerably-useless fashion when given invalid input is to write them in such a fashion as to block any otherwise-useful optimizations the rules would have allowed.

LMAO

Wankers? The only wanker is the one who didn't pay attention to t he video and understand why. As he already pointed out, many people had ALREADY created their own macros using words like "bool" and "uint8" etc, so they needed to use keywords which were different and underscores like "_Bool" etc... were the answer.

...and usually the linker adds some more lol

And a garbage collector, am I right? /s

#include or use GLFW or SDL or FreeGLUT to use OpenGL and BOOM you have access to the GPU. #include I think and BOOM you have audio. Well, you need first to install the correspoding libraries and link everything in the linker, but I doubt you know what I am talking about. Go back to Ruby, Javascript or whatever inefficient and crappy language you like.

@@cutemath8225 I'm pretty sure he was joking.

@@nexusclarum8000 guess it's a r/woooosh/ then

C is fast as it is for a reason.

It's a carry-over from C++ land where enunciating "ess-tee-dee" before everything from the standard library is clunky and extremely repetitive, so most people shorten it to something resembling "stood" or "stud".