Re: Thoughts on Gengtype and Single Inheritance
>>> GRAMMAR
>>>
>>> Support adding a second discriminator. This support is not for
>>> multiple inheritance, but for single inheritance when a second
>>> discriminator is used to further refine it. Look at struct
>>> tree_omp_clause. It contains a sub union. We can represent the
>>> hierarchy like:
>>>
>>> struct tree_omp_clause : tree_common {
>>> location_t locus;
>>> enum omp_clause_code code;
>>> };
>>>
>>> struct tree_omp_default_clause : tree_omp_clause {
>>> enum omp_clause_default_kind default_kind;
>>> };
>>>
>>> struct tree_omp_schedule_clause : tree_omp_clause {
>>> enum omp_clause_schedule_kind schedule_kind;
>>> };
>>>
>>> struct tree_omp_reduction_clause : tree_omp_clause {
>>> enum tree_code reduction_code;
>>> };
>>>
>>> We use TREE_CODE to understand that we have at least a tree_omp_clause
>>> and then we use tree_common.code to to distinguish these last three.
>>>
>>> Another possible case is tree_type_symtab inside tree_type_common.
>>>
>>> The syntax would be something like the following.
>>>
>>> enum F { F1, F2, F3, F4, F5 };
>>>
>>> class CTYPE GTY ((desc ("%h.kind"), tag ("F1")))
>>> : GTY ((tag ("EC"))) public BTYPE
>>> { public: enum F kind; something *pq; ... };
>>>
>>> class FTYPE : GTY ((tag ("F2"))) public CTYPE { ... };
>>
>> I wonder if the second discriminator support is easily generalizable
>> to enabling any derived class being a root class on it own with its
>> own subtree? If I understand correctly, the GTY syntax would be the
>> same.
>
> If I understand correctly, you are suggesting multiple inheritance
> via enums. I think it is possible, but I think the tag syntax
> would need to be changed to more directly associate the tag with
> the variable.
>
> --
> Lawrence Crowl
I was trying to talk about single inheritance, not multiple
inheritance nor composition here, but perhaps I misunderstood it
myself.
As I saw it, there is a hierarchy rooted at tree_common. For its child
tree_omp_clause there is further sub-hierarchy. It's all single
inheritance, and the second discriminator here would be the first
discriminator, if tree_omp_clause were not a child of other class.
--
Laurynas
Re: [libstdc++] Mis-configure _GLIBCXX_LONG_DOUBLE_COMPAT?
.. let's add Jakub in CC, he knows those bits better than anyone else, and I don't think they changed much lately anyway. Paolo.
GCC debug info question (PR 54061, mips coprocessor registers)
I have a question about GCC debug info. The tests
gcc.c-torture/compile/mipscop-[1234].c fail when compiled
with -g on MIPS (they are mips specific tests). This has
been reported in bugzilla as PR 54061.
The problem is:
register unsigned int cp0count asm ("$c0r1");
This is a coprocessor register and in mips_option_override
we set mips_dbx_regno for this register to INVALID_REGNUM
This means that DBX_REGISTER_NUMBER returns INVALID_REGNUM
and we abort on the assert in dbx_reg_number in dwarf2out.c.
My understanding is that gdb doesn't know how to handle mips
coprocessor registers so I think gcc should just not put out
any debug information for this register variable. Is that
possible? I couldn't find anyway to do it in GCC. Or should
GCC just put out the register number for DBX_REGISTER_NUMBER
instead of INVALID_REGNUM even if gdb may choke on it?
Steve Ellcey
sell...@mips.com
Request for comments on language extension: Safe arrays and pointers for C.
We have proposed an extension to C (primarily) and C++ (possibly) to address buffer overflow prevention. Buffer overflows are still a huge practical problem in C, and much important code is still written in C. This is a new approach that may actually work. The proposal, "Safe arrays amd pointers for C, round 2", is here: http://www.animats.com/papers/languages/safearraysforc41.pdf This has been discussed on Lambda the Ultimate and comp.std.c, and the flaws found in those discussions have been dealt with. So far, no one has found a killer reason why this can't work. The proposal is to combine the concepts of C variable length array formal parameters and C++ references. This allows passing arrays as arrays, rather than pointers. For "strict mode" translation units, arrays must be passed in this way. For compatibility with old code, strict mode code can call non-strict mode code, and vice versa. When strict mode code calls strict mode code, there is checking to insure that sizes match. This approach doesn't require array descriptors or "fat pointers". Example: Standard UNIX/Linux/Posix read, new strict form: int read(size_t n; int fd, void_space(&buf)[n], size_t n); The array parameter as a sized reference, an array of size n. "void_space" is a new type, like "void *" for type matching purposes, but like "char" for space allocation. The initial "size_t n;" is an existing GCC extension, a forward parameter declaration, needed because the array parameter precedes the size parameter. In non-strict code, this can be called with the good old form: char inbuf[512]; int stat = read(somefd, inbuf, 512); The size is not checked in non-strict code. In strict code, the compiler would generate a size check, based on the prototype, that the size of the actual parameter matched the size of the variable length formal parameter. In strict code, arrays generally have to be passed around as references, to keep the associated size information. There's also a way to do this for structs. So this goes beyond C variable length arrays. Again, there are no array descriptors; declarations tell the language where to find the size of an array. So code is compatible at the object level. There's more, but that's the main idea. Programs would be migrated to strict mode from the bottom up. First standard libraries, then security-critical libraries, then security-critical applications. What I'd like for now is an an estimate of how hard this would be to implement in GCC. Most of the necessary features, or something close to them, are already implemented in GCC. Implementors, please comment. Thanks. John Nagle Animats
Re: Request for comments on language extension: Safe arrays and pointers for C.
My comments are: * TL;DR. * No specification given at the level of edits to C11. * At a glance, no or inadequate explanation of why library solutions and appropriate coding practices (such as the use of managed string libraries) are inadequate. * How does this compare to the array size checking you get with _FORTIFY_SOURCE in glibc (and associated GCC extensions)? * How does this relate to various cases in the secure coding rules draft TS (a specification for static analyzers, but should still be relevant here if you can point to examples of bad code therein that would be detected reliably through use of your proposals)? * Why hasn't this been done before - what is so novel that avoids the pitfalls encountered by previous related work? An insightful analysis of such work and the issues - not necessarily technical - with it is needed to demonstrate there is a genuine difference here. * Is this really in accordance with the Spirit of C? * In general we're skeptical of new language extensions given the problems historically associated with past ones. Assessing what pitfalls there might be in a proposal and the work required to implement it is itself a substantial amount of work (I'd guess several hours at least for this document); it's more likely to happen if there's something to excite people about the proposal (as well as if all the other issues I list are addressed), and I don't see anything particularly exciting here. That's especially the case given how many previous attempts there have been at addressing this sort of issue. * If proposals are written by people with substantial experience in C compiler implementation they are more likely to be sound - what such experience has gone into writing this document? * Consider attending a WG14 meeting and presenting the proposals in person there (having had them included in a pre-meeting mailing), if you want a wider range of implementer opinions. -- Joseph S. Myers jos...@codesourcery.com
gcc-4.6-20120831 is now available
Snapshot gcc-4.6-20120831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 190842 You'll find: gcc-4.6-20120831.tar.bz2 Complete GCC MD5=e71c8a2b2e69fb6dcd84ee241f843386 SHA1=b96533bec7d4152ba94b52d5d50cf4daaad5e1c5 Diffs from 4.6-20120824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Request for comments on language extension: Safe arrays and pointers for C.
On 8/31/2012 3:32 PM, Joseph S. Myers wrote: > My comments are: > > * TL;DR. Then, perhaps, commenting is premature. > * No specification given at the level of edits to C11. That's correct. This is still an informal proposal. > * At a glance, no or inadequate explanation of why library solutions > and appropriate coding practices (such as the use of managed string > libraries) are inadequate. If that approach was going to work, it would have succeeded by now. Safer C string libraries date back to the 1980s. New ones are still being proposed. > * How does this compare to the array size checking you get with > _FORTIFY_SOURCE in glibc (and associated GCC extensions)? There's a long history of guard-word schemes for detecting heap overruns, but none have been enormously successful. The FORTIFY_SOURCE mechanism is interesting, but can't check the cases where size information has been lost before the point of checking. With C arrays, the size information is always known at array creation, but can be lost as the array is passed around. This proposal is about not losing size information. > * How does this relate to various cases in the secure coding rules > draft TS (a specification for static analyzers, but should still be > relevant here if you can point to examples of bad code therein that > would be detected reliably through use of your proposals)? The "Arrays" section of the CERT guide, https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=263 is a style guide, not a spec for hard checking. See "ARR30-C. Do not form or use out of bounds pointers or array subscripts". > * Why hasn't this been done before - what is so novel that avoids the > pitfalls encountered by previous related work? That's a good question. It was tough to fit this into the existing world of C, C++, and existing code. It turns out, however, to be possible. It's the addition of C++ references to C that makes this work. C++ references provide a way to reference arrays without losing size information. This proposal merely generalizes C++ references, along the lines of C variable length arrays, to handle cases where size information is non-constant. That provides, at last, a way to pass arrays around in C without losing size information. > An insightful analysis of such work and the issues - not necessarily > technical - with it is needed to demonstrate there is a genuine > difference here. Reading onward to page 17 of the paper, where SAL, Cyclone, and the Safe C compiler are discussed, may be helpful. The alternatives either lead to a new language (like Cyclone), or heavy run time overhead (like the Safe C compiler). Microsoft's Structured Annotation Language provides syntax for specifying length. But those are just annotations; they're not used by the actual code or for checking. C99 variable length array parameters also provide syntax for associating dimension information with arrays passed to function. But, during conversion to a pointer, the length of the first dimension is lost. So the dimension information passed is just a comment; it's not used, checked, or accessible within the program. The only use for that feature is multidimensional array indexing. > * Is this really in accordance with the Spirit of C? There is a school of thought that celebrates the freedom of the C programmer to write bad code. The fact that we have millions of machines exploited by buffer overflows on a regular basis perhaps indicates that such freedom can be misused. > * In general we're skeptical of new language extensions given the > problems historically associated with past ones. Assessing what > pitfalls there might be in a proposal and the work required to > implement it is itself a substantial amount of work (I'd guess > several hours at least for this document); it's more likely to happen > if there's something to excite people about the proposal (as well as > if all the other issues I list are addressed), and I don't see > anything particularly exciting here. That's especially the case > given how many previous attempts there have been at addressing this > sort of issue. There's certainly a history of failure in this area. That's why it's worth looking at something that might work. > * If proposals are written by people with substantial experience in C > compiler implementation they are more likely to be sound - what such > experience has gone into writing this document? > > * Consider attending a WG14 meeting and presenting the proposals in > person there (having had them included in a pre-meeting mailing), if > you want a wider range of implementer opinions. That may happen, but I'm still getting comments informally at this point. I'd like to see enough of this implemented in GCC as an extension that people could try it out. John Nagle Animats
