Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Two options of a program to find a track in the list |
| Date | 2015-10-23 09:03 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <n0db36$n70$1@dont-email.me> (permalink) |
| References | <8855e43f-e1f3-47b8-9b45-989687dd97e7@googlegroups.com> <n0bamj$9g0$1@dont-email.me> <46021cd2-aee9-41f6-8038-65bbb362f502@googlegroups.com> |
On 10/23/2015 4:16 AM, Alla _ wrote:
> <snip>
>
> Thank you for your reply. I have few questions.
>
> I. sizeof(all_tracks) / sizeof(all_tracks[0]);
>
> how does sizeof work with all_tracks, which have a matrix form?
For context, the declaration was
char all_tracks[][80] = { ... initializers ... };
As you'd expect: sizeof(all_tracks) is the number of bytes of memory
devoted to all_tracks. Also, sizeof(all_tracks[0]) is the number of
bytes devoted to all_tracks[0], that is, it is 80. Divide the grand
total amount of memory by the amount used for one element, and you
get the number of elements.
Note: In sizeof(all_tracks) and sizeof(all_tracks[0]), the
parentheses are optional. I've inserted them just for ease of reading;
they could just as well have been omitted:
int entries = sizeof all_tracks / sizeof all_tracks[0];
Use 'em or lose 'em as your taste dictates. However, when you apply
sizeof to a type name (rather than to an expression), the parentheses
are required:
int doubleBytes = sizeof double; // Wrong!
int doubleBytes = sizeof(double); // Right.
> 1) I know that sizeof computes the amount of bytes,
> and includes a terminating null character; hence, when
> it returns, for example, 9, it means that there are 8
> characters + the null character. How does 9 fits into
> later computations; does the machine understand that
> the length (the amount) of entries is actually 8 characters
> + the null character?
sizeof has nothing to do with, and no knowledge of, the contents
that may happen to be stored in the object whose size it computes.
All sizeof does is tell you how many bytes are set aside, not what
may or may not be in those bytes.
For a char[] array that happens to contain a string, it follows
that sizeof must be greater than strlen(). This is because strlen()
stops as soon as it finds the '\0', while sizeof stops for nothing.
> 2) Also, I don't understand how
> sizeof(all_tracks) / sizeof(all_tracks[0]);
> works with a matrix.
>
> 'Sizeof (all_tracks)' - does this pick up all rows,
> thus taking into account only the first bracket (i-th part)
> of all_tracks [] []?
>
> Wouldn't 'sizeof(all_tracks[0])' return the number of
> characters (which is the number of columns) in this
> particular first row all_tracks[0]?
I think I've covered this, above. For emphasis: sizeof reports
*all* the bytes of the object, whether they are part of a string's
"payload" or not.
> II. " ... and I'm pretty sure it's not. fgets() stores all the
> characters you type (if they fit), including the '\n' at the
> end of the line. Is there a '\n' anywhere in the program's list
> of tracks? No, there is not -- and therefore, nothing matches.
>
> Your mission (should you decide to accept it): Find the '\n'
> that fgets() stored in `search', and get rid of it before trying
> to match against the track titles."
>
> This is amazing, and interesting. I see what you mean.
>
> I've tried to put sizeof(search) instead of 80 in
> fgets (search, 80, stdin); same result:
>
> Allas-MacBook-Pro:headfirst Alla$ ./strstrpage85A
> Enter your track name: Dancing with a Dork
>
> And nothing more comes out of this program.
Because the '\n' is still present in the search string, but
not in the material being searched. You won't get rid of the '\n'
by any shenanigans with sizeof; you'll need to search for it (the
strchr() function seems a good choice) and then remove it (by which
I actually mean "overwrite it with '\0' so it's no longer part of
the search string").
> 1) They say in the book that "if you are passing a
> pointer to fgets(), do not use sizeof, but enter
> the size you want", because sizeof pointer will be
> always 4 or 8 (by storing only the address of a pointer
> itself, and not the address it refers to). Although I do
> not pass a pointer to fgets in this case, I use an integer
> instead of sizeof, as they do it in the book.
What they're talking about is:
char array[42];
char *ptr = array;
int n1 = sizeof array;
int n2 = sizeof ptr;
In each case, sizeof returns the number of bytes for its own
operand. n1 is therefore 42, but n2 is probably not: On most
machines nowadays, n2 will be 4 or 8, the number of bytes used
for storing a pointer, not the number of bytes in the thing it
happens to point at.
This can be a trap for the unwary, because of the way C
treats arrays when written as function parameters:
int func(char array[42]) {
return sizeof array;
}
You might expect this function to return 42, but it almost
certainly will not. Remember, array arguments are silently
rewritten as pointers, so the function actually looks like
int func(char *array) {
return sizeof array;
}
... and as with n2 above, you get the number of bytes in a
pointer, not the number of bytes in an array.
> But, in case I do pass a pointer and need to use an integer
> in fgets, or I just decide to use an integer, do you think
> that using the following might work?
>
> char search[80];
>
> printf ("Enter your track name: ");
> fgets (search, 80, stdin);
>
> find_track (search [i-1]);
>
> /** when passing search into find_track function, I subtracted
> the last character that fgets() stores, i.e. supposedly '\n',
> is it correct? **/
No. You're still confused about what a "string" is in C.
It's not a "first-class object" (as in some other languages);
rather, it's just a char[] array with a specific convention for
formatting the contents. The individual char's of the array
are always there, whether they participate in a string (they're
near the beginning) or not (they're after the '\0').
> 2) Interestingly enough they do not have any such problem
> in the book - neither do they mention it, nor does it
> effect their code, which I reproduced word for word. I
> wonder if this '\n' is the issue in my case, although
> it does sound plausible.
Perhaps they're using the EVIL gets() function? Unlike
fgets(), gets() automatically removes the '\n'. But gets() is
UNSAFE AT ANY SPEED, and any book that encourages you to use it
should be BURNED, preferably under the fanny of its author.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-22 11:30 -0700
Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-22 14:44 -0400
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:16 -0700
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:22 -0700
Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 10:52 +0100
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 09:57 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 02:35 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:59 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:42 -0700
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:47 -0700
Re: Two options of a program to find a track in the list Barry Schwarz <schwarzb@dqel.com> - 2015-10-23 11:02 -0700
Re: Two options of a program to find a track in the list Geoff <geoff@invalid.invalid> - 2015-10-23 11:24 -0700
Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 10:39 +0100
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:03 +0100
Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 11:21 +0100
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:36 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 02:42 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:10 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:24 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:45 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:00 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 17:16 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:47 -0700
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 13:19 +0100
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 15:38 +0100
Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 10:57 -0400
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 15:59 +0100
Re: Two options of a program to find a track in the list David Brown <david.brown@hesbynett.no> - 2015-10-23 17:25 +0200
Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 11:55 -0400
Re: Two options of a program to find a track in the list Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-23 10:45 -0600
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 16:55 +0100
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 17:21 +0100
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 17:23 +0100
Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 12:58 -0700
Re: Two options of a program to find a track in the list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-23 02:19 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:28 +0100
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 11:12 +0100
Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 13:42 -0700
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 22:14 +0100
Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 22:28 +0100
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 22:47 +0100
Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 23:21 +0100
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-24 01:37 +0100
Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 14:52 -0700
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 23:06 +0100
Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 16:39 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:26 +0100
Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-24 22:28 +0100
Re: Two options of a program to find a track in the list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 15:26 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 23:44 +0100
Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 09:03 -0400
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:10 -0700
Re: Two options of a program to find a track in the list Geoff <geoff@invalid.invalid> - 2015-10-23 11:21 -0700
Re: Two options of a program to find a track in the list Barry Schwarz <schwarzb@dqel.com> - 2015-10-22 14:50 -0700
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:25 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:00 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:36 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:04 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:58 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 12:07 +0100
Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:28 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 18:04 +0100
Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 13:31 -0400
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:21 +0100
Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 13:45 -0700
Re: Two options of a program to find a track in the list Ian Collins <ian-news@hotmail.com> - 2015-10-24 10:32 +1300
Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 15:33 -0700
Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:24 +0100
csiph-web