Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164735
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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