On 28/10/2024 4:25 pm, Jan Beulich wrote:
> On 28.10.2024 17:18, Andrew Cooper wrote:
>> On 28/10/2024 4:12 pm, Jan Beulich wrote:
>>> On 28.10.2024 17:07, Andrew Cooper wrote:
>>>> On 28/10/2024 4:03 pm, Jan Beulich wrote:
>>>>> As with 9cbf61445cda ("xen/earlycpio: Drop nextoff parameter"): While
>>>>> this is imported from Linux, the parameter not being pointer-to-const is
>>>>> dubious in the first place and we're not plausibly going to gain a write
>>>>> through it.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>>>> You haven't tried compiling this, have you?
>>> Of course I have. Is there any subtlety with compiler versions? Or what
>>> else am I missing?
>> struct cpio_data's copy of this field is non-const (which you keep on
>> noting that new compilers will object to),
> New compilers? I'm afraid I'm missing context. With gcc14 the patch builds
> fine. I didn't try _older_ ones (but I see no reason why they might object;
> see below).
>
>> and you can't change that
>> without breaking the build in microcode.
> I don't need to change that, "thanks" to
>
> cd.data = (void *)dptr;
>
> casting away const-ness. That is - compilers ought to be fine with the
> change; Misra won't like it.
You have literally complained about patches of mine on the grounds of
"GCC is about to start caring about casting away const on a void pointer".
So which is it.
>
>> Nothing of this form can be taken until the constness is consistent in
>> microcode, after which yes it can mostly become const.
> We can move there in steps, can't we?
Or you can stop trying to insist that I rebase around an
incorrect/incomplete patch, just for the sake of the const of one void
pointer, which can still be laundered by this function.
Especially when you could wait the ~day it will take to get an
otherwise-good series in, and then change cpio and get all of the const
problems in one go.
~Andrew
