| From: Jeff Johnson <[EMAIL PROTECTED]> | Successful private data types should be named according to semantic | usage, not implementation attributes.
I very much agree. Even if C isn't really helpful for this. | rpmuint32_t and rpmuint8_t are just scaffholding to get <stdint.h> | out of the way while I get better data types (like rpmiob) into rpm's API | instead. | | I really couldn't care less what an integer or an octet is called. But | this is like the 4th or 5th time I've been forced to rename rpm integers | and octets ... I don't know the issues here. But if you are informed by the former thought you must be headed the right way. The <stdint.h> stuff mostly facilitates what I consider bad practices. Having said that, I would expect that you could get away with the <stdint.h> names and thus help readers. On systems that do not have <stdint.h>, define them. I haven't read the code in question, so I don't know why you found it awkward to do this. I would expect you to need logic analogous to this to define your private versions. One advantage of using the conventional name is that the reader should already have the meaning cached. Editors and other tools are less important (but often less flexible). I think that the official linux kernel policy is best: code for the present and put shims in to make code work in the past. It is tempting to do the reverse but it impedes progress. The <stdint.h> types are here to stay (even if I feel they are not often the right tool). ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List [email protected]
