On Thu, Jul 25, 2013 at 7:06 AM, Zdenek Styblik <zdenek.styb...@gmail.com> wrote: > Dan, > > I agree that some changes aren't as best as they could be, eg. > checking some return values, and I admit there is still some work > left. I hope code got simpler and compiler shut. Anyone is free to > iterate on these changes and make code better. > >> So the changes to the patch that I submitted look completely >> unnecessary, but harmless. > > Now, I don't know what you mean. I took your changes into account and, > actually, they're there. I just wanted to iterate a bit more. >
What I mean is that the changes that you added to my changes do not change the generated code. They just add more words to the source code. Changing: fseek(fd, blah, blah); to tmp = fseek(fd, blah, blah); then never looking at 'tmp' will generate the exact same object code because 'tmp' will just be optimized out. Therefore it is unnecessary to write the 'tmp =' part. That's why I said that the extra changes are unnecessary. They do not change anything in the program's behavior or functionality. If you add the checks of these return codes, that _will_ change the program's behavior (I personally think that it's kind of unnecessary, but...). >> sorry for the original diff format. I have no idea how to drive CVS. > > No worries. I've applied your patch and then did % cvs diff -u ; to > get unified output. Also, I hope all is in since I've split your patch > into smaller chunks. In retrospect, I could have handled it > differently and perhaps even better - like apply and commit your patch > and then do the re-works. Well, next time. It's fine... The changes were all there. > There are still those(two) scanf() patches left. I want to look at > these closer, because it seems tricky to handle scanf() correctly. It's really not _that_ tricky. It returns the number of things that it scanned in correctly. > I mean, not just patch it up. Well I didn't just patch it up.. I tried to handle them correctly. > I hope we'll be good to remove > -Wno-unused-result after these two. yeah, I'd really like that because, like I said it totally breaks the compilation on even fairly recent gcc versions. >> I see you are using git as well.. > > Yes, especially if I want to change multiple things. I just check-in > file/files, do the changes, export diffs. > >> Is there any chance we can get the >> whole tree converted to git and get rid of this CVS stuff? > > I have no idea how to convert CVS to git(here at SF.net). But it's > possible to have git, yes. oh man.. that's great to hear. It just so happens there is a tool 'cvs2git' which does a great job of converting the CVS tree to git. That's what I originally used. We just need a list of contributors so that we can properly map the email address names used in cvs to real names. http://cvs2svn.tigris.org/cvs2git.html I ran it once and everything looked really good in it. It saved all the old revisions and tagged all the releases in what looked to me like the right place. The other option is to just chose some point and start the git repo from that point, but it would be nice to have the full change history if possible. I'm sure that SF.net supports git.. From there we should just be able to push a git tree to it and it should "just work". I'd be willing to work on this if everyone is ok with potentially moving to git. thanks dan ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
