Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Fri, 24 Jan 2025 20:32:32 -0500
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <vn1evg$2g0m7$1@dont-email.me>
References: <87a5bgsnql.fsf@gmail.com> <vn066i$28bkd$2@dont-email.me>
 <20250124121027.691@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 25 Jan 2025 02:32:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="754b368ecbae64992e68fbeb07ea14bc";
	logging-data="2622151"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EHwZu26acNbvBQvF9uvktVYH3Ji/n0rk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:3iYF8lTAYvuj5quZvrpStcvFweM=
Content-Language: en-US
In-Reply-To: <20250124121027.691@kylheku.com>
Bytes: 3863

On 1/24/25 15:24, Kaz Kylheku wrote:
> On 2025-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> One of the most important goals of the C standard is backwards
>> compatibility.
> 
> Backward compatibility matters in software.

C code is software, and so are C implementations, so I'm not sure what
that has to do with anything. The committee has explicitly stated a
priority between those two kinds of software: "existing user code
matters; existing implementations don't". That means it's OK for a new
version of the C standard to require a rewrite of C implementations, but
requiring a rewrite of existing code to work with the new standard is to
be avoided.

> People use C compiler applications to open text documents of type C.
> 
> All that matter is that there is a way to use their old document
> with the new application.

And to be able to use it in a mode where it fully supports all of the
new features of the C implementation.

> It is almost purely a software matter, not requiring anything in the
> specification.

The specification needs to make it clear what users can and cannot
expect of the implementation - because that kind of thing is within the
responsibilities of the C standard. They can expect that a new version
of C will seldom (ideally never, but that generally cannot be achieved)
intrude upon the space of names previously reserved for users, so they
won't have to change their code to continue working with the new
features of that version.

....
> It doesn't matter if the current language has a keyword "arraysize"
> which breaks every program that uses it as the name of something
> (goto label, struct member, variable, function ...) if
> the language implementation has an option like -std=c11
> under which that is not a keyword.

Backwards compatibility doesn't mean that you can still build your
program using an older version of the language. It means that you can
compile your code your code without change using the newest version of
the language. You only have to make changes to make use of new features
of the language, and you should be confident that you can do so without
worrying about some of the other new features breaking your existing code.
Backwards compatibility is just one of the goals of the C and C++
committees, but it is one of several highest priorities for both of
them. That means that one or another of those other high priorities
causes almost every version of either standard to contain a few features
that do break backwards compatibility. Still, when it is easily avoided,
it should be, and choosing a reserved identifier for new keywords is
dead easy. The concept of reserved identifiers was created precisely for
use in this manner.