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 <alirezaarzehga...@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 > >
