[LCP]Variable Length Arrays in C, support as per C89/C99 in g cc
Y Giridhar Appaji Nag
Giridhar.Nag at ubinetics.co.in
Tue Jul 9 20:29:06 UTC 2002
Hi!
> From: Jack Lloyd [mailto:lloyd at acm.jhu.edu]
> Sent: Monday, July 08, 2002 10:53 PM
> To: 'linuxcprogramming at lists.linux.org.au'
>
> Odd that it
> doesn't give a warning though (are you compiling with "-W -Wall"?).
Yeah! even a -Wall (in addition to -std=c89) does not catch it :(
-pedantic helps though.
> Complying with a particular standard merely means that any
> valid program in
> that language is accepted by the compiler - since VLAs are completely
> undefined by C90, it seems likely that GCC simply accepts it.
But then if it is compliant to c89 (in which there are no VLAs), wouldn't
this be a deviation ... but when I looked once again into the 'info gcc'
pages ... this is what I found (And it explains the behaviour that I did
encounter). Guess I should've RdTFM closely.
The `-ansi' option does not cause non-ANSI programs to be rejected
gratuitously. For that, `-pedantic' is required in addition to
`-ansi'. *Note Warning Options::.
and ...
`-pedantic'
Issue all the warnings demanded by strict ISO C and ISO C++;
reject all programs that use forbidden extensions, and some other
programs that do not follow ISO C and ISO C++. For ISO C, follows
the version of the ISO C standard specified by any `-std' option
used.
...
Some users try to use `-pedantic' to check programs for strict ISO
C conformance. They soon find that it does not do quite what they
want: it finds some non-ANSI practices, but not all--only those
> BTW, your code seems wrong. The variable named 'b' is just an
> int, so you
> can't assign to or read from b[0], b[1], b[2] - presumably
> you meant to use
> a[0], a[1], a[2] there?
Well it atually was "int a" and "int b[a]" was a type that one.
-rgds,
Giridhar
--
Y Giridhar Appaji Nag Giridhar.Nag[@t]ubinetics(.)co.in
While one person hesitates because he feels inferior, another
is busy making mistakes and becoming superior. -Henry C. Link
> an individual are not necessarily those of UbiNetics
More information about the linuxCprogramming
mailing list