On 4/1/19 2:54 AM, Peter Krempa wrote:
On Fri, Mar 29, 2019 at 18:44:04 -0400, Laine Stump wrote:
On 3/29/19 9:33 AM, Peter Krempa wrote:
This was meant to stop abusing the members directly, but we don't do
this for other internal structs. Additionally this did not stop the
test from touching the members. Remove the header obscurization.
I agree with you that this obfuscation does nothing in the face of a hostile
(or ignorant) coder, but if we instead just make the real struct public then
it won't be just ignorant devs who incorrectly use the internals of
virBuffer. How about taking care of it with a virbufferpriv.h as we now do
for several other structs whose internals we want to keep "private"?
vircommandpriv.h is one good example.
Vast majority of our code uses stack'd version. Just grep for use of the
VIR_BUFFER_INITIALIZER macro.
Ah, right. I hadn't noticed that.
If it were possible I'd take it private.
Personally I think it's easy to go overboard making things private
(although I have to admit it does occasionally make it easier to change
the implementation of something without requiring little changes all
over the place).
I think review making sure that people don't do shenaningans with the
struct should be sufficient.
My only misgiving is that there must have been some event leading up to
commit 642b26fab26 back in 2008.
Personally, I'm okay with it. You may want to wait and see if danpb (the
author of the above commit) thinks differently:
Reviewed-by: Laine Stump <laine@xxxxxxxxx>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
