Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Results of survey re. a new array size operator Date: Wed, 29 Jan 2025 08:18:18 -0800 Organization: A noiseless patient Spider Lines: 83 Message-ID: <864j1h1tmd.fsf@linuxsc.com> References: <87a5bgsnql.fsf@gmail.com> <20250124135623.00004479@yahoo.com> <20250124115250.760@kylheku.com> <20250124165243.678@kylheku.com> <868qqu2bnl.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 29 Jan 2025 17:18:18 +0100 (CET) Injection-Info: dont-email.me; posting-host="ba8d9ca2da4b9314498ee7469992f70e"; logging-data="2572767"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+M8QOy+5iVxDfzXXwoH/rbxVEc9StteIw=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:h7wCXbiij5PNUI9EuVjYqNJS+lo= sha1:jQozhqmN1r73CyZcASq/ZIHpV9I= Bytes: 4334 bart writes: > On 29/01/2025 09:48, Tim Rentsch wrote: > >> Kaz Kylheku <643-408-1753@kylheku.com> writes: >> >>> On 2025-01-24, Scott Lurndal wrote: >>> >>>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>>> >>>>> On 2025-01-24, Scott Lurndal wrote: >>>>> You can define >>>>> >>>>> #define arraysize (x) (sizeof (x) / sizeof ((x)[0)) >>>> >>>> You can, but you don't need to. >>> >>> The repetition in things like: >>> >>> sizeof foo->bar.buf / *sizeof foo->bar.buf >>> >>> is just irksome. Why do I have to say that thing twice, >>> to get its number of elements? >>> >>>> Often readability suffers >>>> when you use macros, not to mention the other quirks of >>>> C macro use (in C++, a constexpr function might be >>>> suitable, but the naming being arbitrary (e.g. arraysize, >>>> NUM_ELEMENTS, SIZE, et alia) doesn't aid in readability >>>> or maintainability. >>> >>> The naming being arbitrary is the argument for standardizing the >>> name for the macro and sticking it into, for instance, . >>> >>> If we didn't have offsetof there, we might have to deal with >>> OFFSETOF, offsetof, offset, member_offset, and others. >> >> That's a flawed analogy. A macro to compute the number of >> elements in an array can be done in standard C. The >> functionality of offsetof cannot be done in standard C, and >> that's what it needs to be in the standard library. > > Can't it? The various versions I've seen, including mine, look > like this: > > #define offsetof(a,b) (size_t) &( ((a*)0) -> b) That form of expression is not guaranteed to work, as other responses have explained. > As for the other point that was made, when looking at open source > code, every other program seems to contain macros like > > MAX > ARRAYLEN > STREQ > > But with assorted spellings (the first program I looked at today used > MZ_MAX). > > However, every other program also seems to use typedefs to define > their own versions of INT32 etc, even with stdint.h type being > available for 25 years. Probably historical baggage. It was ten years after C89 that C99 added , and probably five more years before people started using C99 regularly. And it didn't help that Microsoft, in their near-infinite wisdom, didn't ever really support C99, and waited until C11 before doing an implementation conforming to a current C standard. So the pre-C99 names had many years to become entrenched, and after that there was no sufficiently motivating reason to change them. If it ain't broke don't fix it. > So being in the standard is not enough if the official name is > too ugly or it is fiddly to type. Personally I think the type names added in are both ugly and almost always a bad choice for other reasons. That said, I note that uint32_t and uint64_t have become nearly ubiquitous (and also uint8_t, which is completely baffling, since unsigned char can be used instead, along with some form of static assertion for people who are overly obsessive).