Path: csiph.com!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: Thu, 30 Jan 2025 12:13:11 -0800 Organization: A noiseless patient Spider Lines: 67 Message-ID: <86v7twysa0.fsf@linuxsc.com> References: <87a5bgsnql.fsf@gmail.com> <87ldut38zt.fsf@bsb.me.uk> <87frl12lce.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 30 Jan 2025 21:13:12 +0100 (CET) Injection-Info: dont-email.me; posting-host="8398b997425c6ac61eec19d85d38cad2"; logging-data="3256961"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18A5PzB6mFcFx9ktQn/lNXbUZRSTu7OAEE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:YKnDhZg07WkRNrB8gvWlx9K9/bQ= sha1:tLabtSRz/ZB0hiEq6nGoAbINKv8= Xref: csiph.com comp.lang.c:390200 Ben Bacarisse writes: > David Brown writes: > >> On 29/01/2025 17:00, Ben Bacarisse wrote: >> >>> Alexis writes: >>> >>>> JeanHeyd Meneide, a Project Editor for WG14, has just posted the >>>> results of a survey re. the preferred form of a new array size >>>> operator: >>>> >>>> -- https://thephd.dev/the-big-array-size-survey-for-c-results >>> >>> Curious. The top objection to the usual macro solution is given >>> as: >>> * double-evaluation of e.g. getting the size of the 1-d part of >>> a 2-d array >>> int meow[3][4]; /* ... */ SIZE_KEYWORD(meow[first_idx()]); >>> Does the author not know that there is no evaluation of the >>> operands of sizeof in this example? >> >> 6.5.3.4p2 : >> >> """ >> If the type of the operand is a variable length array type, the >> operand is evaluated; otherwise, the operand is not evaluated and >> the result is an integer constant. >> """ >> >> I don't know if that is the source of the double-evaluation concern >> here, but it is certainly a situation in which sizeof /does/ >> evaluate its operand. > > It would have been a good idea to pick an example that behaves as > claimed. Let's hope this sort of casual approach is reserved for > blogs. All of the motivational examples listed are lame. Everyone knows that macro calls might evaluate an argument twice, and so to avoid calling macros on expressions with side-effects. It's true that the usual macro definition to determine array extent misbehaves but that can simply be called out as a warning without needing to codify the situation by putting it in the C standard; in other words it's a quality of implementation issue, not a language issue (and some cases are already diagnosed by both gcc and clang). As for the problem of name collision, choosing a longer name and having it be all caps (as most macro names should be) gives a collision cross section that is vanishingly small. Either of the names ARRAY_INDEX_LIMIT() or ARRAY_EXTENT() are both descriptive enough and unlikely-to-collide enough that they can be used without any significant danger of collision. What would be better is to give some general tools that would allow a user-defined macro to be written safely. For example: _Has_array_type( e ) 1 if and only if the expression 'e' has array type _Is_side_effect_free( e ) 1 if and only if the expression 'e' has no side effects, so multiple evaluations have no negative consequences Furthermore because these tests are likely to be called only inside macro definitions, using the _Leading_capital style of naming shouldn't be a problem.