July 31st, 2025
mind blown1 reaction

A consequence of the weird wReserved value at the start of the DECIMAL structure

Raymond Chen
Raymond Chen

Not too long ago, I explained why why there is a weird wReserved value at the start of the DECIMAL structure. Markus Grohs pointed out in a comment that the way that decVal is overlaid on top of a VARIANT means that you have to be careful about the order in which you set the fields.

Given

DECIMAL value = ⟦ some value ⟧;
VARIANT var;
VariantClear(&var);

then you have to remember to set the vt last because it is overwritten by the wReserved inside the DECIMAL.

// Wrong
var.vt = VT_DECIMAL;
var.decVal = value; // oops, the wReserved overwrites the var.vt.

// Better
var.decVal = value; // the wReserved overwrites var.vt
var.vt = VT_DECIMAL; // but we fix it up immediately

The extra wReserved in the DECIMAL is like a bulky backpack that you wear as you go about your daily business. You usually forget that you have it on, until you turn around in a tight spot and accidentally knock something over.

Category
Old New Thing
Topics
Code

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

7 comments

Discussion is closed. Login to edit/delete existing comments.

Sort by :
  • Dave Gzorple

    And then the compiler, assuming it’s gcc, knows that it can assign the fields in any order so it swaps the two around, then sees that the vt gets overwritten so optimises it out, and your careful:

    // Better
var.decVal = value; // the wReserved overwrites var.vt
var.vt = VT_DECIMAL; // but we fix it up immediately

    gets turned into:

    // Better
var.decVal = value; // the wReserved overwrites var.vt

    This is not snark, gcc will actually do things like this, leaving you with almost-impossible-to-find bugs.

    • DB

      So you have a pre existing bee in your bonnet about GCC, and are posting speculation about how it might reorder something that it almost certainly won’t in reality, on a post about a Windows specific element that no one will be using GCC for. Useful!

      • DB

        My point is that I agree with another commenter, that we don’t think GCC is allowed to reorder assigns to members of unions, or that it will actually be THAT capricious in reality. So imo, speculating without specific evidence just reads like unsubstantiated fear/uncertainty/doubt about a compiler that annoyed you once.

        I’m not saying optimizers can’t be very surprising sometimes, but it’s usually for an ultimately logical (if not intuitive, obv) reason and doesn’t break such basic uses (i.e. ones that aren’t in any ‘Do not!’ intro)

      • Dave Gzorple · Edited

        It was a general comment about being careful with what compilers, for example mingw-w64, i.e. gcc for Windows, might do. As such I’d say it’s pretty useful, but you’re free to ignore it if you disagree.

    • Stephan Leclercq · Edited

      I would say that gcc can reorder assignment of fields of a struct, but here decVal and vt overlap, so they obviously must be in an union (I checked the spec, they are indeed) and gcc won’t re-order that.

      Also, wouldn’t you get a compiler warning that the value assigned to vt is overwritten by the assignme to decVal?

      • Stephan Leclercq

        The philosophy of C is that the programmer is responsible for sanitizing the inputs to a function. If you expect that adding a compiler specific keyword will magically sanitize inputs on your behalf, then indeed you will be disappointed…

      • Dave Gzorple

        With gcc you never can tell, code that's fine with one release can silently break on the next one as someone introduces a new "clever" optimisation. So it's hard to say one way or the other.

        In terms of warning, the gcc philosophy is not to warn since you, the developer, should have known better. An example of this from a few years ago is the nonnull attribute, which you can decorate function parameters with to indicate that it's an error if a null pointer is passed in for that parameter. You'd expect gcc to report an error,...

        Read more

Read next