Deutsch   English   Français   Italiano  
<87r04qbeph.fsf@nosuchdomain.example.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Sat, 25 Jan 2025 16:28:58 -0800
Organization: None to speak of
Lines: 67
Message-ID: <87r04qbeph.fsf@nosuchdomain.example.com>
References: <87a5bgsnql.fsf@gmail.com> <vn066i$28bkd$2@dont-email.me>
	<vn16pu$2a1eq$1@paganini.bofh.team> <vn1gdi$2g0m7$3@dont-email.me>
	<vn3kf8$2ji7k$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 26 Jan 2025 01:29:17 +0100 (CET)
Injection-Info: dont-email.me; posting-host="fe08763d6b1c9b85d57c56913c7d5466";
	logging-data="3352604"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uldnO9GRvNLpfwbM1Hq7/"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:/2cqEco6+xbiz04/9edTRTy0oV8=
	sha1:wPBWiSIFsp0OhHSDVjJ7HUx4Pbs=
Bytes: 3912

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).

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */