gnuplot-beta

OK to use anonymous union (C11 feature)? Opinions wanted

[Ethan A M. <me...@uw...>]

Bug reports 2812 and 2813 report and diagnose a problem with color-handling
that manifests on ARM architectures but not on x86.  More detail is attached
to bug 2812 if you want gory details.

The basic issue is that different code is needed if color is represented by
a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
(e.g. "splot foo with pm3d fillstyle transparent solid 0.25").

It is possible to modify the code by inserting an appropiate cast to either
   color.lt = (int)value     or    color.lt = (unsigned int)value
everywhere that it matters.

However IMO a cleaner approach is to modify the t_colorspec structure
using an anonymous union to distinguish between the two cases:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  typedef struct t_colorspec {
      colortype type;                 /* TC_<type> definitions below */
      union {
          int lt;                               /* used for TC_LT, TC_LINESTYLE */
          unsigned rgbcolor;      /* used for TC_RGB */
      };
      double value;                    /* used for TC_CB and TC_FRAC */
  } t_colorspec;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

That allows to write code like
    if (color.type == TC_RGB)
	color.rgbcolor = value;
    else
	color.lt = value;
I have a tested this out in a private git branch and it works as intended.

HOWEVER, anonymous unions were only added to the C standard in C11,
although both gcc and clang already supported them well before that.

So the question is, is it worth adding a requirement for C compiler that supports
C11 or at least supports anonymous unions?
As of gnuplot version 6 we're requiring c99 (version 5 was ok with c89).
MSVisualStudio claims to support c11 as of 2019.   I don't know what other
compilers people might be using, or what their level of support might be. 

What do you think?
Add it to the development version and back it out if compiler problems
are reported?   What about the stable version?  

	Ethan

Re: OK to use anonymous union (C11 feature)? Opinions wanted

[Bastian M. <bma...@we...>]

I fully support making use of a 14-year-old standard. 
https://gcc.gnu.org/projects/c-status.html  lists that gcc actually 
supports anonymous unions since version 4.6, with some support since 
version 3. Official builds for Windows use a modern gcc and build nicely 
with clang as well. DJGPP has gcc 14 cross-compilers and the last 
official OS/2 build used gcc 3, but gcc 9.0 or gcc 11.4 are available. 
MSVC has full support since 2016 version 16.8

In summary, c11 should not be an issue for any of the Windows, DJGPP, 
OS/2 platforms. Backing-out in case of issues on certain platforms seems 
like a reasonable approach.

gnuplot requires c99 since quite a while actually. See e.g. the 
discussion in https://sourceforge.net/p/gnuplot/patches/484/ due to old 
versions of MSVC only supporting c89. That patch is from 2010!

While at it: can we also now use the // comments which are part of c99?

   Bastian

Am 01.07.2025 um 08:31 schrieb Ethan A Merritt:
> Bug reports 2812 and 2813 report and diagnose a problem with color-handling
> that manifests on ARM architectures but not on x86.  More detail is attached
> to bug 2812 if you want gory details.
>
> The basic issue is that different code is needed if color is represented by
> a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
> (e.g. "splot foo with pm3d fillstyle transparent solid 0.25").
>
> It is possible to modify the code by inserting an appropiate cast to either
>     color.lt = (int)value     or    color.lt = (unsigned int)value
> everywhere that it matters.
>
> However IMO a cleaner approach is to modify the t_colorspec structure
> using an anonymous union to distinguish between the two cases:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>    typedef struct t_colorspec {
>        colortype type;                 /* TC_<type> definitions below */
>        union {
>            int lt;                               /* used for TC_LT, TC_LINESTYLE */
>            unsigned rgbcolor;      /* used for TC_RGB */
>        };
>        double value;                    /* used for TC_CB and TC_FRAC */
>    } t_colorspec;
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> That allows to write code like
>      if (color.type == TC_RGB)
> 	color.rgbcolor = value;
>      else
> 	color.lt = value;
> I have a tested this out in a private git branch and it works as intended.
>
> HOWEVER, anonymous unions were only added to the C standard in C11,
> although both gcc and clang already supported them well before that.
>
> So the question is, is it worth adding a requirement for C compiler that supports
> C11 or at least supports anonymous unions?
> As of gnuplot version 6 we're requiring c99 (version 5 was ok with c89).
> MSVisualStudio claims to support c11 as of 2019.   I don't know what other
> compilers people might be using, or what their level of support might be.
>
> What do you think?
> Add it to the development version and back it out if compiler problems
> are reported?   What about the stable version?
>
> 	Ethan
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: OK to use anonymous union (C11 feature)? Opinions wanted

[Erik L. <eri...@gm...>]

Hi Ethan,

There is no objection from the macOS side: The compiler I use to generate
universal binaries defaults to c17/c++17.
Let me know if you wish me to try out a development version.

Best,

Erik



On Tue, Jul 1, 2025 at 1:32 AM Ethan A Merritt <me...@uw...> wrote:

> Bug reports 2812 and 2813 report and diagnose a problem with color-handling
> that manifests on ARM architectures but not on x86.  More detail is
> attached
> to bug 2812 if you want gory details.
>
> The basic issue is that different code is needed if color is represented by
> a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
> (e.g. "splot foo with pm3d fillstyle transparent solid 0.25").
>
> It is possible to modify the code by inserting an appropiate cast to either
>    color.lt = (int)value     or    color.lt = (unsigned int)value
> everywhere that it matters.
>
> However IMO a cleaner approach is to modify the t_colorspec structure
> using an anonymous union to distinguish between the two cases:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>   typedef struct t_colorspec {
>       colortype type;                 /* TC_<type> definitions below */
>       union {
>           int lt;                               /* used for TC_LT,
> TC_LINESTYLE */
>           unsigned rgbcolor;      /* used for TC_RGB */
>       };
>       double value;                    /* used for TC_CB and TC_FRAC */
>   } t_colorspec;
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> That allows to write code like
>     if (color.type == TC_RGB)
>         color.rgbcolor = value;
>     else
>         color.lt = value;
> I have a tested this out in a private git branch and it works as intended.
>
> HOWEVER, anonymous unions were only added to the C standard in C11,
> although both gcc and clang already supported them well before that.
>
> So the question is, is it worth adding a requirement for C compiler that
> supports
> C11 or at least supports anonymous unions?
> As of gnuplot version 6 we're requiring c99 (version 5 was ok with c89).
> MSVisualStudio claims to support c11 as of 2019.   I don't know what other
> compilers people might be using, or what their level of support might be.
>
> What do you think?
> Add it to the development version and back it out if compiler problems
> are reported?   What about the stable version?
>
>         Ethan
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: OK to use anonymous union (C11 feature)? Opinions wanted

[Hans-Bernhard B. <HBB...@t-...>]

Am 01.07.2025 um 08:31 schrieb Ethan A Merritt:

> The basic issue is that different code is needed if color is represented by
> a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
> (e.g. "splot foo with pm3d fillstyle transparent solid 0.25").

I should, in theory, be about equally easy to shift the values of the 
enum up into the unsigned range, by way of an offset.  But that will of 
course lead to some level of confusion between the numeric value 
presented to the user, and the actual numbers seen in, e.g., a debug 
session.

OTOH, looking at that union in a debugger might be equally confusing. 
Mileage will vary.

That said, I'm kind-a surprised that this only shows up now.  Surely 
gnuplot has been running on countless ARM Macs, Raspberry PIs and 
similar things for ages.  And yet this was never seen before?  To me 
that feels like a hint that the actual problem may be not what we 
currently think it is.

> However IMO a cleaner approach is to modify the t_colorspec structure
> using an anonymous union to distinguish between the two cases:

I'm not quite convinced that an _anonymous_ union is really better than 
a named one, for this purpose, but the difference is small enough to be 
ignored.

> So the question is, is it worth adding a requirement for C compiler that supports
> C11 or at least supports anonymous unions?

Setting aside whether anonymous unions are sufficient reason to do it 
right now, the switch itself is probably a good idea anyway.