Re: [PATCH] refactoring: yes: Remove unused and complex condition

[Alireza Arzehgar]

Pádraig Brady <P@draigBrady.com> writes:

> Right that is usually the case.
> That check it to ensure the argv operands
> are laid out appropriately in memory,
> and is best to keep to handle esoteric systems
> where that might not be the case.
Thanks for your reply.
I am very interested in understanding what  cases need these checks.
What kind of platforms can destroy the true form of memory layout on this
program ?
Can we add some tests to re-implement these cases ?
Can we add a comment above of this code to show the purpose of this block ?

> cheers,
> Pádraig
Sincerely yours,
Alireza

On Sun, Nov 20, 2022 at 9:37 PM Pádraig Brady <P@draigbrady.com> wrote:

> On 20/11/2022 13:58, Alireza Arzehgar wrote:
> > I thought for hours to find usage of this code, but unfortunately I could
> > not. Then prepare this patch. I hope this patch was useful.
> > We can refactor this code and make simpler source code. I explained my
> > reasons to remove this conditions on commit message. Reducing complexity
> > and size of code will increase code quality.
> > Anyway, removing this block of code will not change on test result. I
> think
> > one of these options should wrong, test or code. If testing of this code
> > was ignored, then after understanding what this code does, I should add
> > more tests on `yes.sh`.
> >
> > From: alireza <alirezaarzehgar82@gmail.com>
> > Date: Sun, 20 Nov 2022 17:02:24 +0330
> > Subject: [PATCH] refactoring: yes: Remove unused and complex condition
> >
> > Code never pass following conditions:
> >
> > ```
> > if (operandp + 1 < operand_lim
> >            && *operandp + operand_len + 1 != operandp[1])
> > ```
>
> Right that is usually the case.
> That check it to ensure the argv operands
> are laid out appropriately in memory,
> and is best to keep to handle esoteric systems
> where that might not be the case.
>
> cheers,
> Pádraig
>
>