On 28.07.2025 12:50, Frediano Ziglio wrote:
> On Mon, Jul 28, 2025 at 11:46 AM Andrew Cooper
> <andrew.coop...@citrix.com> wrote:
>>
>> On 28/07/2025 11:24 am, Marek Marczykowski-Górecki wrote:
>>> When running xl in a domU, it doesn't have access to the Xen command
>>> line. Before the non-truncating xc_xenver_cmdline(), it was always set
>>> with strdup, possibly of an empty string. Now it's NULL. Treat it the
>>> same as empty cmdline, as it was before. Autoballoon isn't relevant for
>>> xl devd in a domU anyway.
>>>
>>> Fixes: 75f91607621c ("tools: Introduce a non-truncating
>>> xc_xenver_cmdline()")
>>> Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
>>> ---
>>> So, apparently the "No API/ABI change" was a lie... it changed "empty
>>> string" to NULL in libxl_version_info->commandline. Quick search didn't
>>> spot any other (in-tree) place that could trip on NULL there. IMO NULL
>>> value in this case makes more sense. Buf maybe for the API stability
>>> reasons the old behavior should be restored?
>>
>> Hmm, I didn't intend to change things, but I also didn't anticipate
>> libxl__strdup()'s behaviour, or for something to depend on that.
>>
>> While this does turn out to be a marginal API change, I think your
>> solution is the right one. I do not think it's reasonable for there to
>> be one magic pointer that has differing NULL-ness to the others, and
>> NULL for "no information" is the better interface.
>>
>> That said, is the other use fully safe? I can't see anything that
>> requires sprintf()'s %s to detect a NULL pointer and not crash.
>
> That's the standard behavior, usually "(null)" is printed.
Except that such behavior isn't mandated by the C99 spec, afaics. In
fact, strict interpretation of the language there ("the argument shall
be a pointer to the initial element of an array of character type" and
"the argument shall be a pointer to the initial element of an array of
wchar_t type") precludes passing in NULL.
Jan
