Re: [PATCH v2] MIPS: Fix MAX_REG_OFFSET and remove zero-length struct member

[Thomas Bogendoerfer <tsbogend@alpha.franken.de>]

On Fri, Apr 18, 2025 at 10:21:22PM +0200, Thorsten Blum wrote:
> On 18. Apr 2025, at 22:18, Thorsten Blum wrote:
> > On 18. Apr 2025, at 17:14, Maciej W. Rozycki wrote:
> >> On Fri, 18 Apr 2025, Thorsten Blum wrote:
> >>>>> Does regs_get_register() even work for CPU_CAVIUM_OCTEON when accessing
> >>>>> the last two registers because they're both ULL, not UL? (independent of
> >>>>> my patch)
> >>>> 
> >>>> Or rather two arrays of registers.  With 32-bit configurations their 
> >>>> contents have to be retrieved by pieces.  I don't know if it's handled by 
> >>>> the caller(s) though as I'm not familiar with this interface.
> >>> 
> >>> Ah, CPU_CAVIUM_OCTEON seems to be 64-bit only, so there's no difference
> >>> between UL and ULL. Then both my patch and your suggestion:
> >> 
> >> So it seems odd to use `long long int' here, but I can't be bothered to 
> >> check history.  There could be a valid reason or it could be just sloppy 
> >> coding.
> >> 
> >>> I still prefer my approach without '__last[0]' because it also silences
> >>> the following false-positive Coccinelle warning, which is how I stumbled
> >>> upon this in the first place:
> >>> 
> >>> ./ptrace.h:51:15-21: WARNING use flexible-array member instead
> >> 
> >> So make `__last' a flexible array instead?  With a separate patch.
> > 
> > No, '__last[0]' is a fake flexible array and the Coccinelle warning is
> > wrong. We should either ignore the warning or silence it by removing the
> > marker, but turning it into a real flexible array doesn't make sense.
> > I'd prefer to just remove it from the struct.
> > 
> > Stefan or Oleg, do you have any preference?
> 
> Sorry, I meant Thomas, not Stefan.

I don't like the #ifdefery, so please keep __last

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]