Zach, Your work is appreciated, by me and others.
> On Wed, 2009-04-29 at 13:24 -0500, Dick Hollenbeck wrote: > [snip] > >> The C99 stuff is purely arbitrary IMO, there is almost always another >> way to code those things. And rather than ifdef-ing them out, I would >> simply find that other way and offer those changes as patches, removing >> the C99 support altogether if this is really worth your time. >> > > We are talking about removing support for a standard that is supported > by most modern compilers, in order to support an old compiler on one > platform, right? If anything, I think the code should be moving in the > opposite direction. I would like to see us embrace using C99 features, > abandoning support for compilers unable to support a standard that is > now a decade old. > > >From what I can tell based on feedback to the list, the majority -- if > not all -- of developers are using GCC to build OpenOCD. That does not > mean we should support GCC only, but it does suggest that we should work > on moving forward -- not back. MSVC is the first problematic complier > that I have seen reported, and members of the community already have > working CygWin and MinGW32 builds. > These are all the GNU C compilers, just different hosts. So we really only support one compiler that I know of. > While I do not want to prejudge without first seeing a patch, there are > numerous idiomatic expressions required to preserve compatibility with > old compilers, which I believe detract from the readability of the code. > Yes we should not prejudge. I think we may need to get more specific regarding the "C99" features being discussed. C99 is nice in everyway, and I also would not want to give up the entire box of goodies. I may have written C99, and meant C99 "designated initializer". I think if somebody was determined to spend time he could find another way than to use C99 designated initializers. It is my understanding that C99 designated initializers are not supported by C++. If that is wrong, then I cast full support for C99. If that is correct, then I say watch out for C99 designated initializers. In fact I have been contributing inline functions liberally for almost a year now. Zach, I apologize for the confusion. My choice of words cost you the time to write the posting. You and I are on the same page more often than not. > I mean, is it really necessary to continue to place variables at the > start of a block? Would it be so wrong to declare iterator variables in > for loops to limit their available scope? Yes, that is my preference, to put them in the loops like you say. > Aside from MSVC, are there > really other compilers in use here that will not accept such code? > Well, he has not said what the problem is yet. We are starting to get defensive about something that has still yet to reveal itself. And he has not said what version of MSVC he is using, and whether it is still a problem with the latest version. > This group has talked about using trying to use C++ features; why not > simply start by adopting C99 features? Yes, minus the designated initializers if not C++ compatible. > I would not consider using the > former language without a complete rewrite, What? It is only several days to get this project to compile with C++, maybe several weeks to "rewrite" it. (Do we get to peek at the old code when we "rewrite" it? If not, it would be several years.) :) Here is a quick link to C99 high spots: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=215 > but my recent spate of > cleaning for C99 seems to have been well received by community. Treating > errors as warnings has not exposed irreconcilable problems from what I > can tell. OpenOCD appears to be ready to move to C99 today, why give > that up? Note: I am not suggesting we use all C99 features like inline > functions or even variable-length arrays, just avoid moving backwards. > > Due to the lack of prior opposition, I had been debating whether to > simply commit a change that adds -std=c99 and seeing how the community > reacts (since I can now revert it quickly if it poses a real problem). > As there has been a lot going on, I was trying to avoid the distraction > of this debate, but this thread prompts more immediate consideration. > Again, my apologies for not being specific enough. In fact I see now that Igor did say what the problems were: 1) variable declarations not at the start of block 2) designated initializers (.field = value) 3) no unistd.h I have no love for MS VC and I have a great deal of respect for GNU C/C++. So I hereby reverse my opinion, I am only willing to give up designated initializers, not more. Regards, Dick > Cheers, > > Zach > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
