Date: Thu, 28 Jan 1999 04:05:02 -0500 (EST) From: Brian Feldman <green@unixhelp.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@FreeBSD.ORG Subject: Re: -Wall -Wcast-qual and SYSINIT Message-ID: <Pine.BSF.4.05.9901280404120.28225-100000@janus.syracuse.net> In-Reply-To: <199901280753.XAA98980@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Jan 1999, Matthew Dillon wrote:
> Right now we have a problem with struct sysinit.
>
> The problem is that some SYSINIT functions supply a function taking
> a const void * and a const pointer for data, and other SYSINIT
> functions supply a function taking a void * and a non-const pointer
> for data.
>
> What this means, effectively, is that we want one of two SYSINIT
> structures where both the function argument and udata are of the
> same type. Something like the union shown below. If the function
> argument type does not match the data type we want the initialization
> to generate a warning.
>
> struct sysinit {
> unsigned int subsystem; /* subsystem identifier*/
> unsigned int order; /* init order within subsystem*/
> union {
> struct {
> void (*func) __P((void *));
> void *udata; /* multiplexer/argument */
> } n;
> struct {
> void (*func) __P((const void *));
> const void *udata; /* multiplexer/argument */
> } c;
> } u;
> si_elem_t type; /* sysinit_elem_type*/
> };
>
> Unfortunately, GCC isn't smart enough to match the function type
> to the correct structure - it always stuffs it into the first structure.
Overloading a struct? Yuck :(
>
> So the above cool hack will not work :-(.
Overloading is just a bad hack in concept.
>
> I can't think of how to do this without actually having two different
> sysinit structures - on that uses a non-const function and data element,
> and one that uses a const function and data element. While having two
> sysinit structures would work, it would be a little iffy keeping them
> in sync with each other so the kernel init call code doesn't have to deal
> with both types.
>
> struct c_sysinit {
> unsigned int subsystem; /* subsystem identifier*/
> unsigned int order; /* init order within subsystem*/
> void (*func) __P((void *));
> void *udata; /* multiplexer/argument */
> si_elem_t type; /* sysinit_elem_type*/
> };
>
> struct n_sysinit {
> unsigned int subsystem; /* subsystem identifier*/
> unsigned int order; /* init order within subsystem*/
> void (*func) __P((const void *));
> const void *udata; /* multiplexer/argument */
> si_elem_t type; /* sysinit_elem_type*/
> };
>
> The SYSINIT problem accounts for about half the remaining compilation
> warnings. I would like to find a good solution for it.
>
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Feldman _ __ ___ ___ ___
green@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" 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.05.9901280404120.28225-100000>