COM VARIANT nameless union discrimination

Aficionados of COM may remember - because it's been a while, hey? - that the VARIANT structure is a composite of nested union and struct aggregates, as in:

typedef struct tagVARIANT { union { struct { VARTYPE vt; WORD wReserved1; WORD wReserved2; WORD wReserved3; union { LONGLONG llVal; LONG lVal; BYTE bVal; SHORT iVal; FLOAT fltVal;
. . . // and lots more members USHORT *puiVal; ULONG *pulVal; ULONGLONG *pullVal; INT *pintVal; UINT *puintVal; struct { PVOID pvRecord; IRecordInfo *pRecInfo; } __VARIANT_NAME_4; } __VARIANT_NAME_3; } __VARIANT_NAME_2; DECIMAL decVal; } __VARIANT_NAME_1; } VARIANT;

(The full definition is given in https://docs.microsoft.com/en-us/windows/win32/api/oaidl/ns-oaidl-variant.)

The relevant aspect(s) for this post is the apparent use of member names for the anonymous struct/union aggregates - __VARIANT_NAME_1, __VARIANT_NAME_2, etc. They are present because anonymous aggregates are not standard C++ and, prior to C11, were not part of standard C, even though they are commonly supported on many compilers: on supporting compilers, the apparent names are #defined to nothing; on non-supporting compilers they are #defined to, respectively, n1, n2, n3, brecVal, as in:

#if ... some condition ...
# define __VARIANT_NAME_1 n1
# define __VARIANT_NAME_2 n2
# define __VARIANT_NAME_3 n3
# define __VARIANT_NAME_4 brecVal
#else
# define __VARIANT_NAME_1
# define __VARIANT_NAME_2
# define __VARIANT_NAME_3
# define __VARIANT_NAME_4
#endif

This is all fine and well, except when you're writing COM code to work in C++ as well as in C, as is done for various components within the COMSTL project, as in the comstl_C_DECIMAL_compare() function (in comstl/util/DECIMAL_functions.h):

int
comstl_C_DECIMAL_compare(
    DECIMAL const* lhs
,   DECIMAL const* rhs
) /* noexcept */
{
  . . .

    COMSTL_ACCESS_VARIANT_vt_BYPTR(&vdecL) = VT_DECIMAL;
    COMSTL_ACCESS_VARIANT_decVal_BYPTR(&vdecL) = *lhs;

  . . .
}


In order to make it compile for both C and C++, the function is implemented in terms of COMSTL macros such as COMSTL_ACCESS_VARIANT_vt_BYREF(), which is defined as:

#if defined(COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_)

# define COMSTL_ACCESS_VARIANT_vt_BYPTR(pvar) \
           (pvar)->__VARIANT_NAME_1.__VARIANT_NAME_2.vt
#else

# define COMSTL_ACCESS_VARIANT_vt_BYPTR(pvar) (pvar)->vt
#endif

If the (internal / undocumented) COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_ macro is defined, then COMSTL_ACCESS_VARIANT_vt_BYPTR() obtains the vt member via the full retinue of named members; if not, then it obtains vt directly.

So, the question is, how is the COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_ macro discriminated?

It is defined in comstl/comstl.h, and up to STLSoft 1.10.1 beta-16, it was done as:

#if !defined(COMSTL_ASSUME_VARIANT_UNION_FORCE_ARMS_HAVE_NAMES) && \
    defined(_FORCENAMELESSUNION) && \
    !defined(NONAMELESSUNION)

# define COMSTL_ASSUME_VARIANT_UNION_FORCE_ARMS_HAVE_NAMES

#endif

#if defined(COMSTL_ASSUME_VARIANT_UNION_FORCE_ARMS_HAVE_NAMES)

# define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_

#elif defined(STLSOFT_COMPILER_IS_GCC)

   /* GCC has different definitions to the other compilers, so have to treat

    * differently

    */

# if defined(NONAMELESSUNION)

#  define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_

# endif /* NONAMELESSUNION */

#else /* ? compiler */

   /* Other compilers use the MS headers, which test against __STDC__,

    * _FORCENAMELESSUNION and NONAMELESSUNION

    */

# if (  __STDC__ && \

        !defined(_FORCENAMELESSUNION)) || \

     defined(NONAMELESSUNION)

#  define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_

# endif /* (  __STDC__ && !_FORCENAMELESSUNION) || NONAMELESSUNION */

#endif /* compiler */

However, when compiling for MinGW GCC 8.1 today, this no longer suffices.

Searching the web for _FORCENAMELESSUNION and NONAMELESSUNION yielded little, so I did a thorough search of the implementation headers for a bunch of compilers and the Windows SDK, in order to get a (more) complete and up-to-date definition, arriving at the following - hopefully final - definition, which will appear in STLSoft 1.10.1 beta-17:

#if 1 && \
    !defined(COMSTL_ASSUME_VARIANT_UNION_FORCE_ARMS_HAVE_NAMES) && \
    !defined(_FORCENAMELESSUNION) && \
    defined(NONAMELESSUNION) && \
    1

# define COMSTL_ASSUME_VARIANT_UNION_FORCE_ARMS_HAVE_NAMES
#endif


#if 0
#elif defined(_FORCENAMELESSUNION)

#elif defined(COMSTL_ASSUME_VARIANT_UNION_FORCE_ARMS_HAVE_NAMES)

# define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_
#else

 /* The observed extant discriminations are:
  *
  * 1 (VC++ 6):
  *
  *  (__STDC__ && !defined(_FORCENAMELESSUNION)) || defined(NONAMELESSUNION)
  *
  * 2 (*):
  *
  *  (__STDC__ && !defined(_FORCENAMELESSUNION)) || defined(NONAMELESSUNION) || (!defined(_MSC_EXTENSIONS) && !defined(_FORCENAMELESSUNION))
  *
  * 3 (MinGW GCC 4.9):
  *
  *  NONAMELESSUNION
  *  
  * 4 (MinGW GCC 8.1):
  *
  *  (__STDC__ && !defined(__cplusplus) && !defined(_FORCENAMELESSUNION)) || defined(NONAMELESSUNION) || (defined (_MSC_VER) && !defined(_MSC_EXTENSIONS) && !defined(_FORCENAMELESSUNION))
  *
  * which may be better understood as:
  *
  * 1 (VC++ 6):

    0 ||

    defined(NONAMELESSUNION) ||

    (  __STDC__ && \
        !defined(_FORCENAMELESSUNION)) ||
    
    0
  *
  * 2 (*):

    0 ||

    defined(NONAMELESSUNION) ||

    (   __STDC__ &&
        !defined(_FORCENAMELESSUNION)) ||

    (   !defined(_MSC_EXTENSIONS) &&
        !defined(_FORCENAMELESSUNION)) ||

    0
  *
  * 3 (MinGW GCC 4.9):

    0 ||

    defined(NONAMELESSUNION) ||

    0

  * 4 (MinGW GCC 8.1):


    0 ||

    defined(NONAMELESSUNION) ||

    (   __STDC__ &&
        !defined(__cplusplus) &&
        !defined(_FORCENAMELESSUNION)) ||

    (   defined (_MSC_VER) &&
        !defined(_MSC_EXTENSIONS) &&
        !defined(_FORCENAMELESSUNION)) ||

    0
  */

# if 0
# elif defined(NONAMELESSUNION)

#  define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_
# elif defined(STLSOFT_COMPILER_IS_GCC)

#  if STLSOFT_GCC_VER >= 80000 /* NOTE: this number may be wrong - too large, but still old way with 4.9 */

#   if 0
#   elif __STDC__ && \
         !defined(__cplusplus) && \
         !defined(_FORCENAMELESSUNION)

#    define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_
#   elif defined(_MSC_VER) && \
         !defined(_MSC_EXTENSIONS) && \
         !defined(_FORCENAMELESSUNION)

#    define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_
#   endif /* ? GCC version */
#  endif
# elif __STDC__ && \
       defined(_FORCENAMELESSUNION)

#  define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_
# elif !defined(_MSC_EXTENSIONS) && \
       !defined(_FORCENAMELESSUNION)

#  define COMSTL_VARIANT_UNION_ARMS_HAVE_NAMES_
# endif
#endif

If anyone else needs to understand _FORCENAMELESSUNION and NONAMELESSUNION, I hope this post can help.

STLSoft 1.10.1 beta-16 : added stlsoft::count_bits(int)

In the recent 1.10.1-beta16 release of STLSoft, one of the changes was a minor enhancement to the stlsoft::count_bits() function suite, to make working with enumerations simpler.

The prior release(s) contained the following overloads of stlsoft::count_bits():

unsigned

count_bits(

  uint32_t v

) /* noexcept */

;

unsigned

count_bits(

  uint64_t v

) /* noexcept */

;

Pretty discoverable - either pass a 32-bit or a 64-bit unsigned integer. All the use-cases up to now for which I've needed this function have involved one of those types.

However, a new, and probably widely-applicable, use-case popped up. I have a CLI Windows program pown that prints the ownership of a file/directory. It recognises a number of CLI flags, some of which are mutually exclusive, and combines them into a flags parameter (of type int)  that is then passed into the program logic.

Some of the mutually-exclusive flag pertain to how the file path should be shown:

CLI flag	Enumerator
'--show-file-rel-path'	POWN_F_SHOW_FILE_REL_PATH (0x0010)
'--show-file-path'	POWN_F_SHOW_FILE_PATH (0x0020)
'--show-file-stem'	POWN_F_SHOW_FILE_STEM (0x0040)
	POWN_F_SHOW_FILE_MASK_ (0x00f0)

The last enumerator, POWN_F_SHOW_FILE_MASK_,  is a mask for the show-file flags. In order to verify that, at most, a single relevant flag had been specified was code such as the following:

if (stlsoft::count_bits(flags & POWN_F_SHOW_FILE_MASK_) > 1)
{
  . . . // issue contingent report, and ...

  return EXIT_FAILURE; // ... exit the program

}

Neither of the two extant overloads was a best fit, to the compiler said no.

What I needed was an overload that takes an int. But which overload should it invoke?

I could just cast an int to  a uint64_t, but I didn't want to risk any performance costs in code generation in any of the many (versions of) compilers that are supported. Instead, it felt like an opportunity for some, admittedly pretty simple, template metaprogramming.

Without further ado, here's the implementation (with documentation and other stuff elided for brevity):

#ifndef STLSOFT_DOCUMENTATION_SKIP_SECTION

template <size_t N_bytes>

unsigned

count_bits_int_(

  int v

);

template <>

unsigned

count_bits_int_<4>(

  int v

)

{

  return count_bits(static_cast(v));

}

template <>

unsigned

count_bits_int_<8>(

  int v

)

{

  return count_bits(static_cast(v));

}

#endif /* !STLSOFT_DOCUMENTATION_SKIP_SECTION */

unsigned

count_bits(

  int v

)

{

  return count_bits_int_<sizeof(int)>(v);

}

STLSoft 1.10.1 (beta 16) released

The latest beta of STLSoft 1.10.1 is available, at https://github.com/synesissoftware/STLSoft-1.10/tree/beta-16.

Getting the beta

As usual, there are two ways to obtain the latest beta:

1. Select one of the release archives (.zip, .tar.gz) at https://github.com/synesissoftware/STLSoft-1.10/releases/tag/1.10.1-beta16; or
2. Clone the repo https://github.com/synesissoftware/STLSoft-1.10 and checkout the beta-16 branch (as in "$ git checkout -b beta-10 origin/beta-16").

Changes

The substantive changes are:

• added stlsoft_C_environment_variable_exists_a() / environment_variable_exists() (from STLSoft 1.10-alpha)
• added stlsoft::count_bits(int) overload
• added cbegin(), cend(), crbegin(), crend() to platformstl::environment_map
• significant additions and removals of WinSTL file creation functions
• added WinSTL security functions (from STLSoft 1.10-alpha)
• automatic recognising Mac OSX architecture as UNIX
• canonicalising '\file' description sections
• suppresses deprecation warning from reporting use of deprecated functions inside other deprecated functions.

I'll describe some these changes in future blog posts.