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

--===============5657087400202471716==
Content-Type: multipart/alternative; boundary="0000000000005ec7910638df0e24"

--0000000000005ec7910638df0e24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Ethan A Merritt <[email protected]> wro=
te:

> Bug reports 2812 and 2813 report and diagnose a problem with color-handli=
ng
> 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 val=
ue
> (e.g. "splot foo with pm3d fillstyle transparent solid 0.25").
>
> It is possible to modify the code by inserting an appropiate cast to eith=
er
>    color.lt =3D (int)value     or    color.lt =3D (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 =3D=3D TC_RGB)
>         color.rgbcolor =3D value;
>     else
>         color.lt =3D 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 othe=
r
> 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
> [email protected]
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

--0000000000005ec7910638df0e24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Ethan,</div><div><br></div>There is no objection f=
rom the macOS side: The compiler I use to generate universal binaries defau=
lts to c17/c++17.<br>Let me know if you wish me to try out a development ve=
rsion.<br><div><div><br>Best,<br><br>Erik</div><div><br></div><div><br></di=
v></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Jul 1, 2025 at 1:32=E2=80=AFAM Ethan =
A Merritt &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bug reports 2=
812 and 2813 report and diagnose a problem with color-handling<br>
that manifests on ARM architectures but not on x86.=C2=A0 More detail is at=
tached<br>
to bug 2812 if you want gory details.<br>
<br>
The basic issue is that different code is needed if color is represented by=
<br>
a signed integer (e.g. &quot;plot foo lt 2&quot;) or by an unsigned 32-bit =
ARGB value<br>
(e.g. &quot;splot foo with pm3d fillstyle transparent solid 0.25&quot;).<br=
>
<br>
It is possible to modify the code by inserting an appropiate cast to either=
<br>
=C2=A0 =C2=A0<a href=3D"http://color.lt" rel=3D"noreferrer" target=3D"_blan=
k">color.lt</a> =3D (int)value=C2=A0 =C2=A0 =C2=A0or=C2=A0 =C2=A0 <a href=
=3D"http://color.lt" rel=3D"noreferrer" target=3D"_blank">color.lt</a> =3D =
(unsigned int)value<br>
everywhere that it matters.<br>
<br>
However IMO a cleaner approach is to modify the t_colorspec structure<br>
using an anonymous union to distinguish between the two cases:<br>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<br>
=C2=A0 typedef struct t_colorspec {<br>
=C2=A0 =C2=A0 =C2=A0 colortype type;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0/* TC_&lt;type&gt; definitions below */<br>
=C2=A0 =C2=A0 =C2=A0 union {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int lt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0/* used for TC_LT, TC_LINESTYLE */<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unsigned rgbcolor;=C2=A0 =C2=A0 =C2=A0 /=
* used for TC_RGB */<br>
=C2=A0 =C2=A0 =C2=A0 };<br>
=C2=A0 =C2=A0 =C2=A0 double value;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* used for TC_CB and TC_FRAC */<br>
=C2=A0 } t_colorspec;<br>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<br>
<br>
That allows to write code like<br>
=C2=A0 =C2=A0 if (color.type =3D=3D TC_RGB)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 color.rgbcolor =3D value;<br>
=C2=A0 =C2=A0 else<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://color.lt" rel=3D"noreferrer" =
target=3D"_blank">color.lt</a> =3D value;<br>
I have a tested this out in a private git branch and it works as intended.<=
br>
<br>
HOWEVER, anonymous unions were only added to the C standard in C11,<br>
although both gcc and clang already supported them well before that.<br>
<br>
So the question is, is it worth adding a requirement for C compiler that su=
pports<br>
C11 or at least supports anonymous unions?<br>
As of gnuplot version 6 we&#39;re requiring c99 (version 5 was ok with c89)=
.<br>
MSVisualStudio claims to support c11 as of 2019.=C2=A0 =C2=A0I don&#39;t kn=
ow what other<br>
compilers people might be using, or what their level of support might be. <=
br>
<br>
What do you think?<br>
Add it to the development version and back it out if compiler problems<br>
are reported?=C2=A0 =C2=A0What about the stable version?=C2=A0 <br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ethan<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
gnuplot-beta mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">gnu=
[email protected]</a><br>
Membership management via: <a href=3D"https://lists.sourceforge.net/lists/l=
istinfo/gnuplot-beta" rel=3D"noreferrer" target=3D"_blank">https://lists.so=
urceforge.net/lists/listinfo/gnuplot-beta</a><br>
</blockquote></div>

--0000000000005ec7910638df0e24--


--===============5657087400202471716==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============5657087400202471716==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gnuplot-beta mailing list
[email protected]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

--===============5657087400202471716==--