Date: Sun, 25 Mar 2001 13:55:28 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: "David O'Brien" <obrien@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, "Jordan K. Hubbard" <jkh@FreeBSD.org> Subject: Re: cvs commit: src/usr.sbin/sysinstall label.c menus.c Message-ID: <Pine.BSF.4.21.0103251315230.32995-100000@besplex.bde.org> In-Reply-To: <XFMail.010324095430.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Mar 2001, John Baldwin wrote:
> On 24-Mar-01 David O'Brien wrote:
> > You broke the Alpha build:
> >
> > /usr/src/usr.sbin/sysinstall/menus.c:1323: initializer element is not
> > computable at load time
> > /usr/src/usr.sbin/sysinstall/menus.c:1323: (near initialization for
> > `MenuNetworking.items[9].aux')
> >
> > Reverting the "(int)" cast fixes the problem.
I naively looked at the documentation (libdialog.3) to see what was
being cast. The struct member being cast doesn't exist according to
the documentation, of course.
>
> And is bogus. Int on the alpha is 32 bits, where as a const char * is 64 bits.
ITYM that reverting it is less bogus. The cast is just broken on alphas.
The absence of a cast is bogus on all supported systems (it causes warnings).
However, casting to the type that the variable actually has (long, not int)
would work on all supported systems, since long has the same size and
representation as `char *' on all supported systems. It would still be
bogus, and would fail on systems with `char *' larger than long. Casting
to intptr_t would be less bogus but would probably still fail on such
systems (since there would still be an implicit cast to long, and the
intptr_t would probably be truncated).
> Either libdialog needs to be fixed so that dialog.h defines dialogMenuItem.aux
> as a void * rather than a long, or we need to change to having the data field
> point to a struct containing a pointer to a string and a pointer to a submenu
> and have dmenuVarCheck and dmenuSubmenu (or suitable wrappers) just use the
> appropriate pointer from that struct. This is probably the better solution but
> requires more work. :)
The kernel has related problems for `struct config_resource'. It
wants to store a generic value in the same struct member. It uses a
union of { long, int, char * } so that it can hold 3 types of values.
This mostly works OK (except distinguishing between long and int values
is a design error), but it tends to fail for compile-time constants
because C90 can only initialize the first element of a union. It puts
the long type first in the union since longs are more common than
`char *'s and have a better chance of being able to represent `char *'s
and a much better chance of being able to represent ints than vice versa
(longs are actually very uncommon, but ints are common). This still
tends to fail if longs and `char *'s have different sizes. When longs
are smaller, the `char *'s can't fit, and when longs are larger the
compilation system might not be able to expand `char *'s to longs (it
fails to do this in practice on i386's with 64-bit longs). I "fixed"
this using intptr_t instead of long. This fails if intptr_t is too
small to represent longs...
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103251315230.32995-100000>