Re: Results of survey re. a new array size operator

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

antispam@fricas.org (Waldek Hebisch) writes:
[...]

AFAICS there is no trouble.  Namely, before C23 compiler had to
handle undeclared function using "implicit int" rule.

 
You're off by 24 years.  C99 dropped the "implicit int" rule.
 

                                                       So it had
to distingush between declartations, function calls to declared
functions and function calls to undeclared functions.  The
new rule informally could be:
>
  whenever pre-C23 compiler would use implicit int rule and the
  function name is 'countof' use new semantics of 'countof'

 
It would be pre-C2Y.  C23 is frozen, and "countof won't be added to it.
 

There is some complication:  Presumably 'countof' should be
applicable to types.  AFAICS when parser sees 'countof' with no
prior declaration it can activate mode of allowing both
expressions and types.  This should be no big burden as already
'sizeof' gets similar treatment.  So parsing could go on
with minor tweak and the rest can be handled at semantic level.

 
The syntax for sizeof applied to a type is different from the syntax
when applied to an expression:
 
    sizeof unary-expression
    sizeof ( type-name )
 
Of course a unary-expression can be a parenthesized expression, but
there's no ambiguity.
 

AFAICS what I describe is compatible extention: it will treat
any valid C23 program as before and only assign meaning to
previously invalid programs.  At it should be implementable
with modest effort in any C compiler.
>
Of course, it would break compatibility for C compilers that
want to allow undeclared functions as an extention to C23,
but IIUC this is not a concern to the standard.

 
I personally dislike the idea of making countof a reserved identifier
rather than a keyword.  It makes the rules around it more complicated,
which makes the language harder to understand.  And I'm not convinced it
avoids breaking old code.  If the point is to allow for old code that
uses countof as an identifier, then this valid pre-C2Y code:
 
    size_t countof(int *ptr);
    int arr[10];
    countof(arr);
 
would change its meaning (though the existing function couldn't actually
determine the number of element in the array).

Above 'countof' is declared, so with the rule above 'countof(arr)'
would be a function call as before (that the whole point of the
rule, it fires only when use of 'countof' _is not_ valid as
function call).

I understand the need for backward compatibility, but most new editions
of the C standard has broken *some* existing code by defining new
lowercase keywords, starting with inline and restrict in C99.  (C11
added only _Keywords, but C23 adds 11 new lowercase keywords.)
 
I doubt that there's all that much existing code that uses "countof" as
an identifier, and that can be dealt with by compiling it in C23 mode or
earlier.

Some things need to be reserved, for example new declaration keywords.
To remain sane we do want to reserve things like 'if' evan if
tachnically it would be possible to allow redefinition (I did not
check if non-resered 'if' would still allow unambigious parsing,
simply idea of redefining 'if' is too crazy).  But 'sizeof',
'alignof' and similar could be 'non-reserved'.  'sizeof' was
reserved for long time, so there no need to make is non-reserved,
but for new keywords there is compatibility gain.  Basically,
"do not break things without need".  Or to put it differently,
'countof' is a little non-essential nicety.  While it would not
break much code, gain for it is small, so it is not clear that
is justfies any breakage.

--
                              Waldek Hebisch