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

On 2025-01-24, Alexis <flexibeast@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>

The best way to have versioning for this in a C compiler is a
language dialect selection option.

>
Indeed, the article links to a PDF of slides, "Pitch for #dialect
directive" (N3407):
>
  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3407.pdf

That's completely silly.

A source file's dialect preference could be easily communicated
by #define-ing a certain magic macro.

  #define _STD_DIALECT "... some format in here ..."

If that is not appealing, it could be a #pragma:

  #pragma dialect "..."

There is no need whatsoever to invent a new directive for this,
or anything else that is not ... an extension of preprocessing!

If it were an numeric value of type intmax_t, then the implementation's
header files could use ordinary preprocessing conditionals to select
dialect-specific definitions.

Dialects could be defined by 7 arguments, typically a combination
of character and integer constants:

E.g.

  // GNU C, accepted by GCC 11.1.0

  #define _STD_DIALECT _STD_MKDIALECT('G','N','U','C',11,1,0)

The fifth argument is 0 to 32767. The others are 0 to 127.

Standard dialecgts could be identified like this:

  // Standard C from May 11, 2027.
  #define _STD_DIALECT _STD_MKDIALECT('S','T','D','C',2027,5,11)

Dialect integers can easily be tested. An implementation could
test the first four byte to detect whether it supports that
family of dialects at all, and if so, it could switch things
based on the specific numbers. This is easy to do using
nothing but preprocessing, plus the compiler can peek at the
variable also make decisions internally.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca