Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

From: Garrick Peterson <garrickp_AT_gmail.com>
Date: Mon, 27 Apr 2015 08:02:29 -0600

> On Apr 27, 2015, at 2:21 AM, Roberto E. Vargas Caballero <k0ga_AT_shike2.com> wrote:
>
> Again, read [1], section "The use of pointers". Maybe you don't agree with it, but almost
> all the people here agree with it.

Your link shows the use of `node[i].left` as a perfectly valid example when an array is being indexed. And since `cp` is not a structure, there is not enough single-line context to know what `cp` means in the original example.

The use of cp in such a simple loop is not, again to quote your link, "code containing many similar, complex expressions that evaluate to elements of a data structure”, so the use of a pointer is not really justified by just quoting the article. Again, this is without seeing the surrounding code itself, just the snippets presented in the grandparent conversation.

> ANSI C standard, section 3.3.8 (Relational operators):
>
[…]
>
> It is no casuality they added this rule to the standard. They added
> it because is the idiomatic way of running over an array in C. Of
> course CS teachers that liked pascal don't teach it anymore when
> they were forced to move to C, but it is the best way for experienced
> C programmers. Get used to it.

The code in question was not comparing Q against P+1, it was comparing Q against P, where `P = &array[len+1]`, which is a subtly different case. The first increments a pointer by the size of one element, while the second accesses the array element just after the end of the array and obtains a reference to that point in memory. The first is dealing with a number in memory, the second is accessing memory to get a pointer to it. Nothing in the 3.3.8 section affects this.

To make the loop code in question obey the Q < P+1 idiom, it would have to look more like:

    for (cp = colors; cp < &colors[LEN(colors)] + 1; cp++)

I still prefer the `cp - colors < LEN(colors)` version, myself.

-G

Received on Mon Apr 27 2015 - 16:02:29 CEST

This archive was generated by hypermail 2.3.0 : Mon Apr 27 2015 - 16:12:08 CEST