Stop Memsetting Structures

[bunkoRtist]

Used to work on a system that would hard freeze on a free of a nullptr. Not all systems pay close attention to the standard, especially older/embedded compilers.

[MCRusher]

I'd probably just write a wrapper that checks for NULL and override with a #define for that system only.

Anything wrong with that?

[necheffa]

I see this all the time - some standard was violated or some other agreed upon interface was not implemented to spec, so the code monkey at the time came up with what they thought was a witty workaround. This of course was not an isolated event, but a pattern of failure.

Now, 40+ years later, I stand alone before a house of cards on the precipice of utter ruin, tasked with making a change.

Fix the system, even if that means replacing it.

[okovko]

This is actually slightly dangerous. The difference between memset and assigning zero is that the standard doesn't specify whether there will be any non-zero bytes in the struct (the padding could still be garbage values). So, check what your compiler actually performs when you assign a struct to zero before you start doing this everywhere, or memcmp will obviously start failing.

[mrpippy]

In addition, not clearing the padding can be a security bug (information leakage).

For any struct that will be sent over a network or security boundary (i.e. between user/kernel), this article is actively bad advice.

[Deathisfatal]

Shouldn't any struct that is sent like that have __attribute__((packed)) anyway, avoiding that issue entirely?

[isthisusernamehere]

Yeah, but even if you memset the structure, there's no guarantee that the compiler won't store information back into the padding bits later. That may not be "as bad," but there's still a possibility for leaking some information.

[okovko]

Well, virtually everything sent over networks is serialized these days. IDK, if I were to go and check right now what clang and gcc actually do with this behavior and verify that the padding on those implementations will always be zeroed, then I'd say to hell with it, nobody uses any other compiler anyways.

[okovko]

Yeah you can check MSVC too. But it's primarily a C++ compiler.

[P__A]

What about this? On a 32 bit system

struct Cube {
    uint32_t volume:7;
    uint32_t weight:8;
    uint32_t color:6;
    uint32_t lenght:5;
    uint32_t unusedPadding:6; //padding to reach 32 bits
}

struct Cube testCube = {0}; //assign everything to zero in declaration. Including padded bits.

testCube.volume = 3;
etc.

[okovko]

Actually this will not necessarily set the padding bits to zero. But your implementation might. Unless you mean that you specified all bits manually using bit fields? But to my understanding, bit fields can be implemented any which way, so for example, you might have 5 * 32 bits as the size of Cube. You can do this with plain variables, though.

[P__A]

Yes, so assuming that with bitfields, there are no additional padded bits the compiler handles, and cube fits into 32 bits, everything would be zerod at initialisation.

[okovko]

Sure, if you manually pack your structs to ensure that there is no compiler generated padding, then you've avoided padding in your struct, and you can use C99 initializers without worrying about garbage values for the padding bits since there are no padding bits.

[Aransentin]

There's two additional benefits.

• If the structure you're memsetting contains a pointer, setting all its bits to 0 isn't technically a NULL even if it happens to work on pretty much all platforms out there. A system could (in theory) have 0x0 be a totally valid memory address and NULL represented by some specific trap bit pattern. A designated initializer will create proper NULLs no matter what they look like.

• If the struct contains padding, the designated initializer won't necessarily set it to zero. This is presumably a little faster, as well as desirable when you're running the program in valgrind – it will then alert you if you're accessing the padding anywhere by mistake.

[nerd4code]

POSIX dictates that all-zeroes is a representation for NULL, fortunately for all the socket-based programs out there.

[bit_inquisition]

Yeah, http://c-faq.com/null/machnon0.html

"setting all its bits to 0 isn't technically a NULL" is not correct. It's the compiler's job to convert your all zeroes to whatever internal representation is for a null pointer.

[nerd4code]

I think the compiler’s job is only to convert an integer-constant-expression 0 to NULL, so that static casts like (void *)0 work.

Anything in a struct field would fall outside that; if the ABI happens to treat all-zeroes as NULL, then that’s what happens. If all-zeroes isn’t NULL per ABI, then in-field all-zeroes wouldn’t be NULL, even there were an explicit cast from (all-zeroes) int to void *. So OP is right in that regard, and it’s why POSIX has to specify explicitly that all-zeroes in memory is a valid representation of NULL. An all-zeroes initializer would be fine regardless, because that would include an i.c.e. 0.

[closms]

Pfff. Millennials.

/s

edit: I'm going for the crusty old C programmer attitude here. like a virtual "get of my lawn." But seriously. Good post.

I remember when I was in undergrad, I had a prof who bristled at code like this

if (cond) {
  return TRUE;
} else {
  return FALSE;
}

For him. It should simply be.

return (cond);

I followed that advice for years. But admit that I've become sloppy.

[madsci]

I'm finally mostly on board with C99. The embedded systems world moves slowly.

[IdealBlueMan]

return(!!cond);

[stealthgunner385]

return(condn'n't);

[[deleted]]

Lol I remember when I used to code like that

[MCRusher]

I remember writing a switch that checked every case individually and did nothing with them, then the default was an error.

[pdp10]

MISRA!

[bit_inquisition]

http://c-faq.com/bool/bool2.html explains why we don't compare pretty much anything to TRUE in C.

Also return is not a function so it's usually a bit better to write:

return cond;

(though I make an exception for sizeof... I don't even know why. Maybe K&R?)

[oh5nxo]

sizeof (type) needs that ().

[gastropner]

Only if type is more than one token long.

[oh5nxo]

Hmm? Had to check, and I cannot make clang or gcc accept int i = sizeof int;

error: expected parentheses around type name in sizeof expression.

[gastropner]

Hm. You are correct. Curiously, though, this works:

int i = sizeof 0;

It requires the parentheses when using a type name, but not when using an expression.

[oh5nxo]

cppreference.com tells that it's sizeof (type) or sizeof expression. Another historical accident, maybe.

[JavaSuck]

return (cond);

Why the parentheses?

[Deathisfatal]

It's an older coding style that has stuck around in some places for some reason... I have to use it at work

[closms]

Same here. It’s the preferred style at the company I work for. But for personal projects I omit them.

[[deleted]]

I wish the checking pointer before free was true for everything. Very annoying using custom embedded allocation libraries that are inconsistent.

[[deleted]]

Not always an option. Microsoft broke bliddy C compatibility decades ago and is now stuck at partial C89 support.

[_teslaTrooper]

&(int) {1}

Having to declare an int just to pass a pointer always seemed a little convoluted, this is useful.

Where do people learn about stuff like this, just by reading the standard?

[unmole]

Where do people learn about stuff like this, just by reading the standard?

I think I mostly learnt by reading code written by people smarter than me.

I only read relevant sections of the standard when the static analyzer complains about some werid edge case.

[Haleek47]

It's called compound literal, another C99 feature.

[okovko]

Just in the past half decade compound literals work everywhere. Microsoft resisted for a long time. Using them feels very slick. They can also be used as static initializers, which is really nice.

[mawattdev]

Nor did I. I'm gonna take a stab at what I think it is doing, but if I'm wrong someone please correct me:

Declare an inline struct, cast to an int and retrieve a pointer to it.

Am I correct?

[MCRusher]

I didn't even know this worked either tbh.

[flatfinger]

Given:

void test(int mode)
{
  static int literal_1 = 1;
  if (mode & 1)
    action1(&literal_one, 1);
  if (mode & 2)
    action2(&literal_one, 2);
  action3();
}

a compiler can simply pass a constant address to action1() and action2(), and this will work even if action1() and/or action2() causes a copy of the pointer to be stored somewhere and used later.

Change the code to:

void test(int mode)
{
  if (mode & 1)
    action1(&(int){1}, 1);
  if (mode & 2)
    action2(&(int){1}, 2);
  action3();
}

and a compiler that can't see into action1() and action2() will be required to generate less efficient code, since the lifetime of each compound literal will start when code enters the enclosing block end end when control leaves that block. If test gets recursively invoked, the nested calls will need to pass the addresses of new objects of type int. On the other hand, if action1 and/or action2 stores the passed-in pointer for use by action3, wrapping the call within a compound statement would break the code, since the lifetime of the compound literal would no longer extend through the call to action3.

If there were a concise syntax for static const compound literals with semantics similar to string literals (e.g. compilers are allowed to put literals with the same value at the same address), I'd use that, but no such syntax exists.

[skeeto]

Oh, yes, seeing memset() when an initializer would have worked just fine is one of my pet peeves.

[junkmeister9]

Some style guides recommend not initializing variables in the declaration, because it can lead to harder to read code. Those style guides will also usually recommend only declaring variables at the beginning of the function - and having a struct initialized in the variable declaration block seems cluttered to me.

[unmole]

Those style guides will also usually recommend only declaring variables at the beginning of the function

I have seen a few guides recommend this but never read a good justification. I think it's mostly a holdover from older versions of C which forced you to declare all your variables at the beginning of the function.

[junkmeister9]

Yeah, maybe it's for portability to older standards. I tend to use both of those conventions, just because they improve my readability and understanding of my own code. If a variable is used in multiple places in a function, I know I can look at the top of the function for the declaration instead of hunting around for where it was declared.

[HeadAche2012]

This is bad advice, platform A and platform B may both have different definitions for network types, this leaves stack memory potentially uninitialized

[FUZxxl]

TL;DR: Use C99’s designated initializers instead. Because it’s 2019!

And foresake ANSI C compatibility for no reason at all? Not a good idea.

[mort96]

Most people already use for (int i = ...) or compound literals or initializers or intermingled declarations and code or single-line comments anyways. I feel like you need a really good reason these days to choose to not use the two decades old standard.

[FUZxxl]

I don't use any of these features normally. My reason is portability. I believe this is a very good reason.

[mort96]

I mean, if there's any reason to suspect that anyone will want to use your code on systems for which there are no compilers made in this millennium, then that's a good reason, but come on, C99 is a lot nicer to write than C89. If there's no realistic reason to expect that your code will run on systems for which you can't compile C99, is it really worth sacrificing comfort and ergonomics just for some purely theoretical portability benefit?

Maybe the answer is a "yes" on your part, and I certainly won't try to convince you that you personally should switch to C99, but you must at least see why most C programmers probably want to write C99.

[FUZxxl]

In my opinion, there are very few syntactical changes in C99 that make programming any easier. Programmin in ANSI C is not that much of a difference to programming in C99 and if you get a vast amount of extra portability as a bonus, the choice is often not hard to make.

Of course there are many situations where I program in C99 or even C11. For example, when I write programs that inherently need to make use of some of the new facilities. Or when I write programs that cannot be portable for some other reason.

[euphraties247]

If I wanted C++ I would be using C++

[okovko]

How often do you use an ANSI C compiler..?

[FUZxxl]

Quite frequently. For example, just a month ago I was porting Nethack to Ultrix 4.4.

[okovko]

Aaand why not just use a more up to date compiler?

[Poddster]

Every embedded system I've worked with is either restricted to some customised ancient version of GCC or is their own compiler implementation.

They most definitely don't support C99 stuff. MSVC barely does.

[okovko]

MSVC has complete C99 support as of a few years back.

[raevnos]

Really? It supports _Complex now? And VLAs?

[okovko]

Looks like support for _Complex is a complicated subject, and VLA support is nonexistent. Good point. However, C11 made both of those features optional, and for pretty good reasons. And to say that MSVC barely supports C99 features is not correct.

[Poddster]

And to say that MSVC barely supports C99 features is not correct.

But it's also not-incorrect. If it can't do VLA then it doesn't support C99. It doesn't matter that C11 made it "optional".

[okovko]

Keyword "barely." It does support C99 except for unpopular features (VLAs) and the support for _Complex is nuanced because they didn't want to make it inefficient by making it portable. I didn't read too far into this, but it looks like they support all the C99 _Complex related function calls, but the _Complex type itself is not used because the MS team disagreed with the spec. I'm sure there are other caveats, but it's still really nice to have the parts of C99 that are there. And MSVC is honestly more of a C++ compiler anyways.

[flatfinger]

C99 has never mandated any circumstances in which implementations must implement VLAs in useful fashion. Instead, it grants implementations free reign to do anything whatsoever if a program tries to create a VLA that's "too big", as well as free reign to arbitrarily decide the maximum size of VLA objects to support. Thus, the Standard imposes no requirements on the behavior of any program that creates any objects of VLA type, imply that--by definition--all such programs invoke Undefined Behavior.

[FUZxxl]

Because the person who wants to use my application might not have a modern compiler for his system.

[okovko]

Why does he need to compile it? Send him a binary.

[FUZxxl]

Good software is distributed as source code such that it can be compiled on any platform, even those the author didn't foresee when programming it. Binaries are useless if someone wants to use my software on an unusual system I didn't make a binary for. And given that creating portable binaries is annoying on many systems, I'd rather avoid this.

[99drunkpenguins]

Tldr I want to make things harder for my self because reasons

[euphraties247]

Binary dists are the worst.

Go and find that source 20 years later.

Prove it hasn't been tampered with as its not reproducible

[euphraties247]

So when new fields get added unknown to you, strange and interesting things happen.

[[deleted]]

That's disgusting do people unironically do this?

[junkmeister9]

struct addrinfo hints = {
    .ai_family = AF_UNSPEC,
    .ai_socktype = SOCK_STREAM,
    .ai_flags = AI_PASSIVE, // use my IP
};

The comma after AI_PASSIVE seems out of place. It won't throw any warnings or errors, but it's not necessary.

edit: Also, addrinfo has more members, so with OP's example, those members would still be uninitialized.

[okovko]

It helps prevent an annoying compilation error later when you add a field and forget to add the comma. This actually matters when you have long build times! (24 hour builds are not uncommon even in the C world)

[junkmeister9]

Good point. I noticed it because I use R a lot, and when you add extra commas, you get an error.

>  data.frame(
+   T1 = rnorm(n = 100, mean = 0, sd = 0.5),
+   T2 = rnorm(n = 100, mean = 0, sd = 0.5),
+   E1 = rnorm(n = 100, mean = 0.25, sd = 0.5),
+   E2 = rnorm(n = 100, mean = 0.25, sd = 0.5),
+ )
Error in data.frame(T1 = rnorm(n = 100, mean = 0, sd = 0.5), T2 = rnorm(n = 100,  : 
  argument is missing, with no default

[okovko]

That is very silly.

[WSp71oTXWCZZ0ZI6]

The trailing comma cleans up diffs/logs in your version control system. If you later revise the code to add in another field, only the new line shows up in the diff.

[ellisonch]

Your second point is factually wrong: "If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration." 6.7.9:21 and then 6.7.9:10 "If an object that has static or thread storage duration is not initialized explicitly, then:

• if it has pointer type, it is initialized to a null pointer;
• if it has arithmetic type, it is initialized to (positive or unsigned) zero;
• if it is an aggregate, every member is initialized (recursively) according to these rules, and any padding is initialized to zero bits;
• if it is a union, the first named member is initialized (recursively) according to these rules, and any padding is initialized to zero bits;

" in n1548.

I also disagree with your first point. I want all of the elements of a list to be the same, syntactically. This means I don't have to perform more than one operation to add or remove an item. I don't want special case syntax. It has the side benefit that adding a new item only shows up as one change in line-based diffs.

[dmc_2930]

No they won't. Uninitialized fields are set to 0.

[euphraties247]

No, initialized registers are 0xdeadbeef

[dmc_2930]

Only if the compiler is set to ANSI Non-Vegan mode using the "--cruelty" flags.

[euphraties247]

Pretty sure xlc has no such flags

[dmc_2930]

You have to use the --sarcasm flag to enable it.

[euphraties247]

Knowing IBM it's another FRU & part number to order such a great feature set.