[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RESEND PATCH 03/12] golang/xenlight: fix string conversion in generated toC functions
- To: Nick Rosbrook <rosbrookn@xxxxxxxxx>
- From: George Dunlap <George.Dunlap@xxxxxxxxxx>
- Date: Thu, 1 Jul 2021 14:09:47 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eon9sNIahDWrgyFAaZIRX9vSn77mUv2BAx0W5C/4uLU=; b=Wv11+SGLNeQVpLEyxKH+VVC/PnLVi4YRqYSDqnseWqKx1vHQzOgSvwMJwZsonxnTGUCmnBzWqdcubQMjIC+V37TJxBpuJ9UJ+atHyQUztN4Y5NfU95Dx5ltuKM/esv8FkGTS+nOHOV5Nh7k6BuYzykT+VFuecV4JI67CsB8zKTQSOUPmleal4RfWR0yGtmAn+oyEafGZG6WFm/r+WOJGkEJuVynYnXpA02SI0gboHzAGVoNIo8Bh4OH0c666NNUzkf5o2jDH3Smrqu191K5VmiVeWrpJuny9D32z5e9+cJ/YQRkWNwx2jnZCahfw1qWkLVopEwB0UId2aNDCA++5Eg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oodp9vd6P11DdzvMGYL9E6521Yrd6TG3yhfgft3MMBkwVdV30EgPuQIglGIQsx/HzBdddttG4jPBLktByEc0aHDkLjZBjMNluMvAuiPQlXCwcK/7PZAjF/VulDBE461JsxBWkhjsGfMWTy1Z/sYYy7cj78INNAa5X/a3qj52HhCUli7hpSxMnws7t99JLiJ/0NHIP+eotT1im731W8qcjwDxL35WhzgfLzaXqsInTCcV2T0xGpyoiPmP+dPnYuytYJyqxjINwrjf837f6KUa34+QWao/T7b7/U7sMfTzGt8p6UErImO41M/SM7DXe1RfGEXan/hvktJxmVhZZKUHKQ==
- Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Nick Rosbrook <rosbrookn@xxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Thu, 01 Jul 2021 14:10:00 +0000
- Ironport-hdrordr: A9a23:Fk5ipako6LEsygqkS23Q05rCX4LpDfLW3DAbv31ZSRFFG/Fw9/ rCoB3U73/JYVcqKRUdcLW7UpVoLkmyyXcY2+cs1NSZLWzbUQmTXeJfBOLZqlWNJ8SXzIVgPM xbAspD4bPLbGSTjazBkXSF+9RL+qj6zEh/792usEuETmtRGt9dBx8SMHf9LqXvLjM2fqbQEv Cnl6x6jgvlQ1s7ROKhCEIIWuDSzue77q4PMXY9dmcaABDlt0LR1ILH
- Ironport-sdr: o9Qqq7SGbEV6l5QW3XrwILTlDeqGYpAUgteR5Vu1gdwLny5S/sMadyZdRaS+9/Cow6ExD2BDkq g+8eH5/P/qdxQ2F7hoO/ijmGhqJ2S8GWaBVEGxMLPIEH8o4ugdeGl8dbAOTdvfb3bUjqc0O8Kp ruKE9CUBNFJvfEjUNacScMFqzmVCtuYvlIsYKWN7fd4GcHK27zDkHluwv7k6YdepgD1PvBXwlr 9BVZskAfqt3K48DtwIfHckZfL9ribz9Tnf96kCjbUBYnX7tp5G+/ACtpjf4QwUrKAVZ9T9Tl51 c6Y=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHXUNysz1ZbuKJBuU+rSVrlC2Thy6sZwI6AgAUN5YCAD5VSgA==
- Thread-topic: [RESEND PATCH 03/12] golang/xenlight: fix string conversion in generated toC functions
> On Jun 21, 2021, at 5:11 PM, Nick Rosbrook <rosbrookn@xxxxxxxxx> wrote:
>
> On Fri, Jun 18, 2021 at 11:00:26AM +0000, George Dunlap wrote:
>>
>>
>>> On May 24, 2021, at 9:36 PM, Nick Rosbrook <rosbrookn@xxxxxxxxx> wrote:
>>>
>>> In gengotypes.py, the toC functions only set C string fields when
>>> the Go strings are non-empty. However, to prevent segfaults in some
>>> cases, these fields should always at least be set to nil so that the C
>>> memory is zeroed out.
>>>
>>> Update gengotypes.py so that the generated code always sets these fields
>>> to nil first, and then proceeds to check if the Go string is non-empty.
>>> And, commit the new generated code.
>>>
>>> Signed-off-by: Nick Rosbrook <rosbrookn@xxxxxxxxxxxx>
>>
>> So wait — if you do
>>
>> var foo C.typename
>>
>> Then golang won’t automatically zero out `foo`?
>>
>> That seems like a bug really; but assuming this fixes real behavior you’ve
>> encountered:
>
> I would have to dig in again to figure out exactly what Go/cgo is doing
> here, and whether or not this is a bug. But, the behavior I observed was
> that without these nil assignments, I would sometimes get segfaults in
> libxl_string_copy. This patch ensures that libxl__str_dup is not called
> in the empty string case, thus avoiding the segfault.
I skimmed through the CGo page again when I was looking at this, and didn’t see
anything specified about what happens if something is passed to a C function
before being used by golang. If you get a chance, I think it would be good to
try to file a ticket with the golang project, pointing out the observed
behavior, and asking them to either:
1. Document that the golang compiler may not initialize a structure before
passing it in to a C function
2. Document that it *will* initialize values to zero, and fix the bug.
-George
|
