Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!genrad!panda!talcott!harvard!seismo!brl-adm!brl-smoke!smoke!gwyn@BRL.ARPA
From: gwyn@BRL.ARPA (VLD/VMB)
Newsgroups: net.lang.c
Subject: Re:  No. of elements in initialized array
Message-ID: <1441@brl-smoke.ARPA>
Date: Mon, 3-Mar-86 01:30:54 EST
Article-I.D.: brl-smok.1441
Posted: Mon Mar  3 01:30:54 1986
Date-Received: Wed, 5-Mar-86 04:21:20 EST
Sender: news@brl-smoke.ARPA
Lines: 19

> ...  However, code that must look at term_tbl[] needs to know how many
> elements it has.  The solution we're using now is:
>
> #define TERMCOUNT (sizeof(term_tbl)/sizeof(struct termentry))
>
> This works fine on both our Pyramid and our Vaxen.  BUT...is this the preferred
> technique?  Isn't it possible on some machines that the structs may have to
> be padded out to some arbitrary word boundary or something in order to fit
> efficiently into the array (and thus sizeof(term_tbl) may not be an integer
> multiple of sizeof(struct termentry))?  Or will C compilers guarantee that that
> any necessary padding will be included in sizeof(struct)?

The padding is part of the "sizeof" the structure.

#define	number_of_elements(array)	(sizeof(array)/sizeof(array)[0])

This works unless your C compiler is badly broken.  (That CAN happen;
not very long ago I had to use one that insisted that sizeof a string
literal was equal to sizeof(char*).)