Re: [Xen-devel] [PATCH v2 02/22] golang/xenlight: define Defbool builtin type

From: Nick Rosbrook <rosbrookn@gmail.com>
To: George Dunlap <george.dunlap@citrix.com>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	kerriganb@ainfosec.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	Wei Liu <wl@xen.org>
Subject: Re: [Xen-devel] [PATCH v2 02/22] golang/xenlight: define Defbool builtin type
Date: Thu, 5 Dec 2019 10:23:31 -0500	[thread overview]
Message-ID: <CAEBZRSf1CCByv_8xmcQwR=Kwr447WHfu1Sp_Kb=_OSjdDJP-hw@mail.gmail.com> (raw)
In-Reply-To: <a8c4717c-13cd-8061-56a9-006a9aea1913@citrix.com>

> I implemented some tests for these methods to make sure everything
> worked as expected (they did); but there's an unexpected side-effect:
>
> -  *_test.go files cannot `import "C"`

Yeah, this is unfortunate.

> - The fromC / toC methods aren't exported
>
> So it's not possible to do the following check:
>
>   var b Defbool
>
>   b.Set(true)
>   cb, err := b.toC()
>   if ( !C.libxl_defbool_val(cb) ) {
>     // report an error
>   }
>
> defbool_test.go can't `import "C"`, so it can't call
> C.libxl_defbool_val().  We could make an external xenlighttest package,
> but that wouldn't be able to call toC().
>
> (I suppose we could write "proxy" functions for every such function we
> might want to check, but that seems excessive.)

If by "proxy" functions you mean something like:

func libxlDefboolVal(db Defbool) bool {
        return C.libxl_defbool_val(C.libxl_defbool(db))
}

I agree it could be a bit excessive. But, it might be necessary in
order to leverage go test. And, we could make sure that those extra
"proxy" functions are only included in test builds (maybe by making
internal package to house them).

Maybe there is a better solution to this. I'll need to think about it some more.

-NR

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel