Fix up vla, vm and [*] semantics for C
Joseph S. Myers
joseph@codesourcery.com
Sat May 13 01:35:00 GMT 2006
On Fri, 12 May 2006, Mike Stump wrote:
> Review points:
>
> Ok to change typeof(vm) evaluation semantics for gnu89?
>
> Ok to change sizeof (vla) evaluation semantics for gnu89?
Yes.
> Ok to narrow vla usage in structs and unions in gnu89?
VLAs and VM types in structs and unions are a well-established GNU C
extension. They have also caused many problems (especially with
variable-size function arguments). I don't know how widely used it is,
but widely enough to get bug reports (unlike parameter predeclarations).
The appropriate handling is simply to pedwarn-if-pedantic for VLAs and VM
types in structures/unions, for both gnu89 and gnu99.
> Ok to narrow vm with extern in gnu89?
I think so.
> Ok to narrow gnu99 to be more like c99 wrt vla/vm/[*]?
>
> I think based upon the testing results, gnu89 and gnu99 need to leave vlas in
> structures and unions alone, agree? Joseph, want to propose this for the next
> C standard?
New feature proposals aren't for now being considered except through the
TR procedure. I don't think this is a particularly good feature, but if
it's to be deprecated then it needs the full deprecation procedure of
deprecating for release series and removing in a subsequent release
series.
> +bool
> +c_vla_type_p (tree t)
Needs comment.
> + /* True when these areguments had [*]. */
Typo, should be "arguments".
+ if (c_vla_type_p (t1) || c_vla_type_p (t2))
+ break;
Why is this needed when there's
if (d1_variable || d2_variable)
break;
shortly above which should do the same thing?
You use
+ if (was_vm)
+ c_finish_expr_stmt (expr.value);
to evaluate the argument of typeof. Will this ensure the argument only
gets evaluated when the typeof gets evaluated? For example, the typeof
may not get evaluated inside sizeof, or in a cast in conditionally
executed code. sizeof(typeof(VLA)) evaluates the VLA, sizeof(typeof(VM))
doesn't evaluate the non-VLA VM. (If this is hard to fix - involving the
notion of when a type may or may not get evaluated - then fixing the
ordinary C99 cases not involving side-effects in array sizes etc. is still
useful.)
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
More information about the Gcc-patches
mailing list