Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #390200
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Results of survey re. a new array size operator |
| Date | 2025-01-30 12:13 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <86v7twysa0.fsf@linuxsc.com> (permalink) |
| References | <87a5bgsnql.fsf@gmail.com> <87ldut38zt.fsf@bsb.me.uk> <vndmsc$2fau5$1@dont-email.me> <87frl12lce.fsf@bsb.me.uk> |
Ben Bacarisse <ben@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 29/01/2025 17:00, Ben Bacarisse wrote:
>>
>>> Alexis <flexibeast@gmail.com> 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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Results of survey re. a new array size operator Alexis <flexibeast@gmail.com> - 2025-01-24 17:57 +1100
Re: Results of survey re. a new array size operator Michael S <already5chosen@yahoo.com> - 2025-01-24 13:56 +0200
Re: Results of survey re. a new array size operator scott@slp53.sl.home (Scott Lurndal) - 2025-01-24 14:16 +0000
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-24 20:10 +0000
Re: Results of survey re. a new array size operator scott@slp53.sl.home (Scott Lurndal) - 2025-01-24 22:12 +0000
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 00:57 +0000
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 01:48 -0800
Re: Results of survey re. a new array size operator bart <bc@freeuk.com> - 2025-01-29 11:45 +0000
Re: Results of survey re. a new array size operator Michael S <already5chosen@yahoo.com> - 2025-01-29 14:24 +0200
Re: Results of survey re. a new array size operator Richard Damon <richard@damon-family.org> - 2025-01-29 07:24 -0500
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 08:01 -0800
Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-29 11:09 -0500
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 08:18 -0800
Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-24 08:56 -0500
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-24 20:24 +0000
Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-24 20:32 -0500
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 02:40 +0000
Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-25 00:06 -0500
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:13 -0800
Re: Results of survey re. a new array size operator antispam@fricas.org (Waldek Hebisch) - 2025-01-24 23:13 +0000
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 01:17 +0000
Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-24 20:57 -0500
Re: Results of survey re. a new array size operator antispam@fricas.org (Waldek Hebisch) - 2025-01-25 21:18 +0000
Re: Results of survey re. a new array size operator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-25 16:28 -0800
Re: Results of survey re. a new array size operator antispam@fricas.org (Waldek Hebisch) - 2025-01-26 01:48 +0000
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:31 -0800
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-24 19:45 +0000
Re: Results of survey re. a new array size operator Alexis <flexibeast@gmail.com> - 2025-01-25 09:39 +1100
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 01:16 +0000
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:17 -0800
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:19 -0800
Re: Results of survey re. a new array size operator Ben Bacarisse <ben@bsb.me.uk> - 2025-01-29 16:00 +0000
Re: Results of survey re. a new array size operator David Brown <david.brown@hesbynett.no> - 2025-01-29 18:01 +0100
Re: Results of survey re. a new array size operator Ben Bacarisse <ben@bsb.me.uk> - 2025-01-30 00:31 +0000
Re: Results of survey re. a new array size operator David Brown <david.brown@hesbynett.no> - 2025-01-30 10:59 +0100
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-30 12:13 -0800
Re: Results of survey re. a new array size operator scott@slp53.sl.home (Scott Lurndal) - 2025-01-30 21:33 +0000
Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-30 22:31 +0000
Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-02-18 19:46 -0800
csiph-web