ksaunders added a comment. > Just to check -- do you think (some of) these features are something you wish > to propose to WG14 for adoption into C? e.g., are you aiming to get multiple > compilers to implement Plan 9 extensions to demonstrate to WG14 that this is > existing practice in C compilers?
A lot of the Plan 9 extensions were actually adopted by C99 like compound literals and anonymous structures. Although I find these additional extensions interesting and useful, I don't think that they belong in C and they should remain as non-standard extensions. My interests lie in compiling existing code with Clang which utilizes these extensions, rather than encouraging new code to utilize them. There was actually a proposal to add Plan 9 extensions into the Linux kernel, but Linus rejected it. I personally share his opinion that the silent type conversion that the Plan 9 compilers introduce can be problematic. But on the other hand, they are also very powerful when used judiciously. It's on the LKML here if you're interested: https://lkml.org/lkml/2019/1/9/1127 > Does this work for accessing r->FirstLock but give an ambiguous lookup for > r->hold? Or do you only allow one member of the underlying canonical type? Good question. The compilers only allow one member of the underlying type. So you'll get an error saying you've declared `Lock` twice. > Also, why does it require a typedef name? I am not sure, but I presume it is because of cases like this: struct A { int a; }; struct B { int b; }; typedef struct B A; struct Example { struct A; A; }; So it's not clear when you do `example->A` which member you are referring to. If you restrict it to typedef names then you have no ambiguity of this kind. > Ah, interesting. So this is another case where multiple members of the same > type would be a problem. Does this only find structure/union members, or does > this also work for other members? e.g. void size(size_t *) being called with > lock(r)? And if it works for other members... what does it do for bit-field > members which share an allocation unit? It only searches for //unnamed// structure and union members, so non-record members like bit-fields are not used for resolution. That's a good test case I should add as well, yeah. > Thanks for the extra details! Thank you for your interest :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127462/new/ https://reviews.llvm.org/D127462 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
