On Tue, Apr 2, 2013 at 9:04 PM, Dan Gora <dan.g...@gmail.com> wrote: > Actually I just remembered another reason why I hate the stdint.h types: > > When compiling on Ubuntu 12.10: > > ../../lib/ipmi_delloem.c: In function 'ipmi_print_power_consmpt_history': > ../../lib/ipmi_delloem.c:4006:13: warning: format '%lld' expects > argument of type 'long long int', but argument 2 has type 'uint64_t' > [-Wformat] >
Dan, I know exactly what you mean. I've hit the same thing, with different project though, on Debian(and Ubuntu comes from Debian). Heh. I actually don't know what to write in reply and I had several versions already. One thing though. If you don't want to use types from 'stdint.h', don't. I'm not using all of it and all the time. > So, apparently -Wformat is smart enough to check the type, but not so > smart as to be able to check the underlying type, so you get hundreds > of errors like these if you use the uint64_t rather than the standard > c type 'unsigned long long'. > Isn't u/int64_t, resp. all 64_t, exactly the case where it makes sense to use standardized types? Z. > stdint.h made sense for a period of time when the 16 to 32 bit > processor transition was happening and C was a "new" language and > there was ambiguity about the size of an "int", but really I don't see > the point of it anymore. It just causes tons of issues like this. > It's perfectly possible to write the exact same code which will behave > on all (32 and 64 and even a lot of 16) bit processors without any > ambiguity of the size of a data type as long as you don't use 'long' > (unless you want it to match a pointer size). Especially for a > project like ipmitool which has a pretty limited set of processors > which it has to support. > > Anyways, mini-rant against stdint.h over.... > > thanks > dan > > > > > On Mon, Apr 1, 2013 at 3:43 PM, Zdenek Styblik <zdenek.styb...@gmail.com> > wrote: >> On Mon, Apr 1, 2013 at 8:08 PM, Dan Gora <dan.g...@gmail.com> wrote: >>> On Mon, Apr 1, 2013 at 3:04 PM, Zdenek Styblik <zdenek.styb...@gmail.com> >>> wrote: >>>> On Mon, Apr 1, 2013 at 7:52 PM, Dan Gora <dan.g...@gmail.com> wrote: >>>>> yes because the structure is only 3 bytes long. Recall that a long is >>>>> 8 bytes on 64 bit machines. An unsigned int is always 4 bytes (unless >>>>> we're talking about 16 or 8 bit processors here, which we're not...). >>>>> Longs (unsigned or not) should really be avoided unless you're really >>>>> prepared to deal with them being different sizes or 32 or 64 bit >>>>> machines. >>>>> >>>> >>>> Why don't you use int types from "<stdint.h>" that I don't understand. >>>> Is there something wrong about it? Because you'd have equally sized >>>> integers no matter what platform you're currently running at. This >>>> was, actually, one of comments/questions/suggestions I had about >>>> posted patches. >>> >>> Just because I'm not used to using them because I've worked on some >>> platforms which didn't have it and I'm just accustomed to using the >>> underlying standard C types. I can change that though, no problem. >>> >>> thanks, >>> d >> >> No worries. I also didn't mean it as any kind of enforcement. From my >> point it makes sense, or at least in this particular case. Whether it >> makes sense "sense", I can't say :) >> I won't deny I'm trying to push use of <stdint.h> types. >> >> Z. ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
