Zack Weinberg <[EMAIL PROTECTED]> writes: | Mark Mitchell <[EMAIL PROTECTED]> writes: | ... | > Like you, I do think these problems are surmountable; but, also like | > you, I think it would take some time to get all the problems solved. | > I don't really think, though, that this is immediately relevant; | > Gaby's trying to fix things that seem to me like they will actually | > make for better C code, and, right now at least, going to C++ isn't on | > the table. I think you agree that most of the changes Gaby wants to | > make are for the better (with the possible exception of casting the | > return value of malloc, which will be hidden in a macro that's | > probably less error-prone that writing out the malloc calls directly) | > -- but you're concerned about the fact that doing this work now might | > make it too easy for us to switch to C++ without thinking about all | > the issues? | | Yes, that's what I'm trying to get at. Secondarily, I don't want to | lose some of the expressive power of C-that-is-not-C++ if we're not | getting the expressive power of C++ in exchange -- for instance, I | really don't want to have to avoid the set of C++ keywords when coding | in C, or remember the semantic difference between C and C++ struct tags.
But we do not get any expressive power by using C++ keywords. Using C++ keywords just make it impossible to have better checking provided by C++ compilers. That is no gain. It is a lost. Furthermore, if you ever move to C++ as you wanted to do, you will have to abondon those keywords anyway, so it does not represent any essential to expressive power. I find the insistance of using C++ keywords (while wishing for moving to C++) very inconsistent, if not contrary to our coding conventions. | I'd change my tune if Gaby could demonstrate a place where the C++ | compiler caught a user-visible bug that the C compiler missed. That | would be worth the extra discipline. All the bugs described so far, | however, have been things that, while formally incorrect, haven't | affected the visible behavior of the compiler. That is an extreme statement. First, I just complete the project this afternoon. Furthermore, the fact that a function was called with with one argument, but its definition was poking at a second argument is a bug whose effect is hard to trace down correcly. But that was just the first one I came across. Furthermore, the benefits are not just what bugs we can catch right now, but how we make it possible to build free software based on GCC, and encourage more contributions. I know of a number of projects that are done with proprietary compilers, that could have been done with GCC (and people are ready to move to GCC, I know at a number of Codesourcery customers ;-)) if it were possible to have GCC compilable with a C++ compiler. Frankly, there does not seem to be any benefit to obsctructing these patches that would align us with our own coding conventions. | (And I'd be less grumpy about coding to the intersection of C and C++ | if someone coded up warnings for the C compiler to catch things | outside the intersection.) Consider that to be a follow-up that I'm willing to do, if these preliminary patches are in. For sure, I do want to make sure that we do not break things too easily. -- Gaby
