Zack Weinberg <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | [dropping most of the message - if I haven't responded, assume I don't | agree but I also don't care enough to continue the argument. Also, | rearranging paragraphs a bit so as not to have to repeat myself] | | > with the explicit call to malloc + explicit specification of sizeof, | > I've found a number of wrong codes -- while replacing the existing | > xmalloc/xcallo with XNEWVEC and friends (see previous patches and | > messages) in libiberty, not counting the happy confusion about | > xcalloc() in the current GCC codes. Those are bugs we do not have | > with the XNEWVEC and friends. Not only, we do get readable code, we | > also get right codes. | ... | > I don't think so. These patches make it possible to compile the | > source code with a C++ compiler. We gain better checking by doing | > that. | | Have you found any places where the bugs you found could have resulted | in user-visible incorrect behavior (of any kind)?
As I said, I ran a preliminary experiment to estimate how difficult the task would be to have the existing source respect our own coding conventions: http://www.gnu.org/software/gcc/codingconventions.html Avoid the use of identifiers or idioms that would prevent code compiling with a C++ compiler. Identifiers such as new or class, that are reserved words in C++, should not be used as variables or field names. Explicit casts should be used to convert between void* and other pointer types. The mere fact of doing that and catch the errors I mentioned earlier, was quite positive. Of course, I do not doubt that we would find more bugs (and if we do not find any, then we do get another level of confidence in the code), but this is something that happens quicker and go through extensive coverage when it is possible for more people to do. I do believe that the fact that the compiler is relying on a second inexisting argument to do name lookup is a user visible bug (not mentioning stack corruption), but we do get better and existing checking by making the change avaialble to a wider number of people. The benefits are not just the immediate bugs I find. | If you have, I will drop all of my objections. | | > If converting GCC to C++ is your ultimate goal, then I don't think | > you should block these patches. They do not introduce C++, but also | > they do provide a path to local experiments before we ever have any | > huge fight about that. | | To be clear, my ultimate goal is neither to introduce C++ nor to block | it. My goal is to make sure that *if* a transition to C++ happens, it | happens with great care and attention to detail. Part of this is not | doing anything that makes it seem easier to convert to C++ than it | actually is. See my earlier response to Mark. I understand that, but none of the patches is in line of unthinking, that makes any hypothetical move to C++ (nor non-move move-to) difficult. (1) if we move to C++, we have to avoid the keywords (which are already prohibited by our current coding conventions) (2) if we move to C++, we have to avoid the implicit convertion void* -> T* (which is already prohibited by our coding conventions) (3) if we don't move to C++, we still follow our coding conventions. (4) if we don't move to C++, we still can use additional testing provided by a C++ compiler. | > | This isn't an answer to the question I asked. I asked for a more C++ | > | friendly way to code *black box* use of enums, where (in C) one is | > | deliberately relying on the unchecked conversion to and from integral | > | types. | > | > The point was that an enum by itself is a black box. There is no | > foward declaration of enums. There is no need here for an abstraction | > for an abstraction. | | So you don't see any value whatsoever to having (for instance) the | individual constants of 'enum machine_mode' be inaccessible in most of | GCC? 'cos I sure do. What I'm saying is that when you have a name like EXPAND_NORMAL, you do not need to know the value it represents. Just that it names a constant. If you want to introduce a new name for that name, people would still have to use that name, therefore the question is exactly what do you gain in this specific case by introducing a second name (which does not hide more than the first name) over the existing practice where people use numerical values, that you do not gai by introducing just a single layer (enumeration)? -- Gaby
