On Thursday 28 January 2010, Austin, Alex wrote: > ~/Projects $ size openocd.gcc > text data bss dec hex filename > 915920 11600 90668 1018188 f894c openocd.gcc > ~/Projects $ size openocd.clang > text data bss dec hex filename > 902754 10684 90572 1004010 f51ea openocd.clang
So the size difference isn't as significant as your initial numbers suggested ... one could recoup that amount of memory by removing some code duplication at the source level. > > On Thursday 28 January 2010, Austin, Alex wrote: > > > +#ifndef true > > > +#define true -1 > > > > ANSI-C defines true as "1" not "-1" ... best > > to use that for compatibility. > > > > I suspect I'll merge this portability patch with that change... > > That makes little sense to me, especially since I've always > seen TRUE defined as -1. Oh well. Either way shouldn't matter. There's a difference between various common practices and the standard. Classically, "true" is "nonzero" so any nonzero value works ... and that's why having any definition at all can seem strange and arbitrary. Since there are (2^N)-1 true values, why should any one of them be more special? That encourages silly stuff like comparing values which are true (non-false) but not equal to each other... this is math, not philosophy, so all truths should be equal! :) If you want to know why the standard uses 1, there are probably rationale documents circulating. I'd guess one of the reasons is to facilitate "bool == bit" type implementations ... signed bits are nonsensical! - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
