New .nops directive, to aid Linux alternatives patching?

[Maciej W. Rozycki]

On Sun, 11 Feb 2018, Andrew Cooper wrote:

> > I implemented:
> >
> > .nop SIZE [, MAX_NOP]
> >
> > where the maximum size is 255 bytes.  Should we go with
> >
> > .nop MAX_SIZE, SIZE [, MAX_NOP]
> >
> > to support more than 255 bytes?
> 
> If you were to do that, why not simply remove the 255 maximum limit,
> rather than having a user pass two identical numbers?  That said, I
> think the current implementation with 255 is probably fine; My example
> of ~45 is pushing it, but I expect that any example trying to use 64 or
> more almost certainly has a better way to do the same thing.

 What's the point of this arbitrary limit though?  Does it have any 
benefit to the user?

 Otherwise may I remind what the GNU Coding Standards say [1]:

'Avoid arbitrary limits on the length or number of any data structure, 
including file names, lines, files, and symbols, by allocating all data 
structures dynamically.  In most Unix utilities, "long lines are silently 
truncated".  This is not acceptable in a GNU utility.'

?  I think this principle applies here as well.

References:

[1] <https://www.gnu.org/prep/standards/standards.html#Semantics>

  Maciej