Re: New .nops directive, to aid Linux alternatives patching?

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Feb 12, 2018 at 12:42 AM, Maciej W. Rozycki <macro@mips.com> wrote:
> 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

Support arbitrary .nop directive size requires very intrusive changes
and provides very little benefits.

> structures dynamically.  In most Unix utilities, "long lines are silently
> truncated".  This is not acceptable in a GNU utility.'

Agreed.  Assembler will issue an error when it happens.

> ?  I think this principle applies here as well.
>
> References:
>
> [1] <https://www.gnu.org/prep/standards/standards.html#Semantics>
>
>   Maciej



-- 
H.J.