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

[Kaz Kylheku]

On 2022-11-20 23:04, Alireza Arzehgar wrote:
> 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 ?

Any kind of platform!

I think, POSIX doesn't require that successive argument
strings in an argument vector --- argv[0], argv[1], argv[2] --- are
consecutively laid out in a larger character array, like this:

  "firstarg\0secondarg\0...."

The GNU yes program checks whether that arrangement happens to be the
case and takes advantage of it. If the arguments are laid out like that,
then the null bytes in between just have to be turned into spaces to
turn them into one string.

I don't think that what the code is doing is well-defined according
to ISO C, because it constitutes out-of-bounds array access.

It's the same like

  {
     int a[1] = { 10 };
     int b[1] = { 20 };

     if (&b[1] == &a[0]) {
        int ten = b[1]; // obtain 10
     }
  }

ISO C allows a pointer one byte past the end of an array to be
calculated. That pointer may be safely compared to other pointers.
It may  not be dereferenced, though.

The idea in the yes program is that if the relationship between
the arguments holds true, then that constitutes a proof that the
objects have been allocated in a single array-like object by
the system mechanism which invoked the main function.

If that is the case, then the pointer manipulation is valid.

Similarly we can fix the above undefined code to make it
strictly conforming:

  {
     int arr[2] = { 20, 10 };
     int *b = arr, *a = arr + 1;

     if (&b[1] == &a[0]) {  // unconditionally true npw
        int ten = b[1];     // obtain 10
     }
  }

Since a and b are now pointers into the same array object,
everything is fine.

> Can we add a comment above of this code to show the purpose of this block ?

The code is completely transparent to someone who is halfway qualified
to touch it.

Do you have a repro test case which demonstrates an actual issue with
the GNU Coreutils yes program?

It seems that you're just picking it apart trying to understand it,
and making patches before you've reached a complete understanding.

For the purposes of learning, rather than fixing a problem, it is
best for the student to understand the actual code. Ignore or cover up
any comments, study the code and then compare notes with the comments.