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


Groups > comp.lang.c > #164735

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

From Meredith Montgomery <mmontgomery@levado.to>
Newsgroups comp.lang.c
Subject Re: on looking up a word in a table, pointer question
Date 2022-01-30 10:23 -0300
Organization Aioe.org NNTP Server
Message-ID <86k0eh4ash.fsf@levado.to> (permalink)
References <86k0ejbly8.fsf@levado.to> <st1qka$ka3$1@dont-email.me> <st1tk8$ka3$2@dont-email.me> <87pmobxoek.fsf@bsb.me.uk>

Show all headers | View raw


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.  The lesson there was that a pointer has a type that
must be noticed.  Pointer arithmetic is dependent upon the type of the
pointer.  My intuition of what a pointer is improved immensely.

> To the OP: remember, this does not work inside a function where you
> have a pointer to the first element, rather than an array proper: table
> is the name of an array outside the lookup function, but it's a pointer
> inside it.

That's right --- I was bitten by that in this case.  The macro

  #define NKEYS ((sizeof table) / (sizeof table[0]))

happens to do 8/16 == 0 in that procedure where table is a pointer.
That /struct kw/ happens to occupy 16 bytes in my system.  Alignment
reasons, I suppose.  The members themselves should occupy 8 + 4 bytes
in my system because I have a pointer to char and an int.

struct kw {
  char *word; 
  int count;
};

> I've been caught out by this, so I always avoid parameter names that
> shadow array names.  gcc even has a warning you can turn on for this,
> though it is more general than I'd like.

I might just start doing the same because I did fall for the same and it
probably took me over an hour to realize the trouble.  (Learning
immensely lately.)

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