Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #164736

Re: on looking up a word in a table, pointer question

From Bart <bc@freeuk.com>
Newsgroups comp.lang.c
Subject Re: on looking up a word in a table, pointer question
Date 2022-01-30 13:44 +0000
Organization A noiseless patient Spider
Message-ID <st64op$su5$1@dont-email.me> (permalink)
References <86k0ejbly8.fsf@levado.to> <st1qka$ka3$1@dont-email.me> <st1tk8$ka3$2@dont-email.me> <87pmobxoek.fsf@bsb.me.uk> <86k0eh4ash.fsf@levado.to>

Show all headers | View raw


On 30/01/2022 13:23, Meredith Montgomery wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>
>>> On Fri, 28 Jan 2022 22:27:22 +0000, Lew Pitcher wrote:
>>>
>>>> On Fri, 28 Jan 2022 18:16:15 -0300, Meredith Montgomery wrote:
>>
>>>>> struct kw * lookup(char *word, struct kw * table, int n) {
>>>>>    struct kw *p;
>>>>>
>>>>>    for ( p = table; p->word != NULL; p++) {
>>>>>      if (strcmp(word, p->word) == 0)
>>>>>        return p;
>>>>>    }
>>>>>
>>>>>    return NULL; /* not found */
>>>>> }
>>
>>> Gawd, I shouldn't post on an empty stomach. And, I'm too used to using
>>> char pointers that I forgot about array entry length computations.
>>> (Excuses, excuses... mea culpa)
>>>
>>> I meant
>>>    for ( p = table; p < (struct kw *)((char *)table + sizeof table); p++) {
>>> because
>>>    1) pointers increment by the size of the thing they are pointing to
>>>       so, here, we have to make (table + sizeof table) increment in
>>>       char rather than struct kw, so we coerce <<table>> into char
>>>    2) pointers compare to pointers of the same type, so we must coerce
>>>       the results of ((char *)table + sizeof table) /back/ into a
>>>       struct kw * before we compare to <<p>>
>>
>> But, as has been pointed out, table is a pointer here, not an array, so
>> sizeof table is of no use at all, no matter how you scale it.
>>
>> However, when you really /do/ have an array called table, the usual way
>> to get its size is to write sizeof table / sizeof *table.  That's
>> clearer, in my opinion, than casting pointer types.
>>
>> Second however, since I'm a bit odd, I would write (&table)[1] to get a
>> pointer just past the end of the array:
>>
>>    for (struct kw *p = table; p < (&table)[1]; p++) ...
> 
> You taught me this already in previous threads --- one where I had a
> pointer to an array of 13 chars.  (You showed this solution then.  I
> then commented on the terminology of ``end of the array''.)  I was
> bitten there that by adding one to that pointer it advanced 13 chars and
> I couldn't see why.

It /is/ difficult to see why. I believe that if you have to stop and 
think about something, then you ought to find a different way of doing 
it. Others may be confused too.

Or at least, use a macro:

   #define ENDOF(table) ((&table)[1])   // address of last+1 element

Then it can be used like this:

#include <stdio.h>

   int main(void) {
       int table[] = {10,20,30,40};

       for (int* p = table; p < ENDOF(table); ++p) {
           printf("%d\n", *p);
       }
   }

Although I would personally avoid one past the last element business, 
and do it like this:

   #define ENDOF(table) (&table[(sizeof(table)/sizeof(table[0])-1)])

   int main(void) {
       int table[] = {10,20,30,40};

       for (int* p = table; p <= ENDOF(table); ++p) {
           printf("%d\n", *p);
       }
   }

Now ENDOF is the actual last element, not the following one. (This 
requires 'table' to be a proper, dimensioned array; probably the first 
does too, but that's harder to see.)

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

on looking up a word in a table, pointer question Meredith Montgomery <mmontgomery@levado.to> - 2022-01-28 18:16 -0300
  Re: on looking up a word in a table, pointer question scott@slp53.sl.home (Scott Lurndal) - 2022-01-28 21:29 +0000
  Re: on looking up a word in a table, pointer question Meredith Montgomery <mmontgomery@levado.to> - 2022-01-28 18:49 -0300
  Re: on looking up a word in a table, pointer question Kaz Kylheku <480-992-1380@kylheku.com> - 2022-01-28 22:07 +0000
    Re: on looking up a word in a table, pointer question Meredith Montgomery <mmontgomery@levado.to> - 2022-01-28 22:03 -0300
  Re: on looking up a word in a table, pointer question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-28 22:23 +0000
    Re: on looking up a word in a table, pointer question Meredith Montgomery <mmontgomery@levado.to> - 2022-01-28 22:05 -0300
    Re: on looking up a word in a table, pointer question James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-28 21:10 -0500
  Re: on looking up a word in a table, pointer question Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-01-28 22:27 +0000
    Re: on looking up a word in a table, pointer question Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-01-28 23:18 +0000
      Re: on looking up a word in a table, pointer question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-29 02:32 +0000
        Re: on looking up a word in a table, pointer question Meredith Montgomery <mmontgomery@levado.to> - 2022-01-30 10:23 -0300
          Re: on looking up a word in a table, pointer question Bart <bc@freeuk.com> - 2022-01-30 13:44 +0000
    Re: on looking up a word in a table, pointer question Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-01-28 23:23 +0000

csiph-web