Sujet : Re: Two questions on arrays with size defined by variables
De : antispam (at) *nospam* fricas.org (Waldek Hebisch)
Groupes : comp.lang.cDate : 09. Feb 2025, 15:29:00
Autres entêtes
Organisation : To protect and to server
Message-ID : <voae3a$2rke4$1@paganini.bofh.team>
References : 1 2 3
User-Agent : tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
Janis Papanagnou <janis_papanagnou+
ng@hotmail.com> wrote:
And in "C" (C99) I tried it *without* the _inner block_
main ()
{
int n = 5;
char * arr[n];
...
}
and it seemed to work that way. (In those other languages that wasn't
possible.)
Hmm, IIRC both (Extended) Pascal and PL/I allow VLA within function
in places where they allow variable declarations, so really no
special _inner block_ requirement (just must be local to a function).
Q1: Is this a correct (portable) form?
VLA objects have to be declared locally. However, keep in mind that
support for local declarations of VLA _objects_ is now optional (i.e.
not portable). Support for variably-modified _types_ themselves (VLA
types) is mandatory. But you are not guaranteed to be able to declare an
actual VLA variable.
I fear I don't understand what you're saying here. - By "now" do you
mean newer versions of the C standards? That you can rely only, say,
rely on it with C99 but maybe not before and not in later C standards
conforming compilers?
For my purpose it would be okay to know whether with the C99 version
(that I used) it's okay, or whether that's some GNU specific extension
or some such.
This used to be GCC extention, AFAIK present in all versions of
GCC. It was standarized in C99 and is now available in reasonable
C compilers like curent tcc (Tiny C). But AFAIK it is not present
in Microsoft C. And probably not present in historic C compilers
like compilers for old proprietary Unices or historic tcc (Tendra
C compiler). As already mentioned compiler can claim C11 or C23
compliance but do not implement VLA (VMT are optional in C11
but mandatoryu in C23, VLA are optional both in C11 and C23).
-- Waldek Hebisch