> If you want portable code, i'd refrain from using underspecified > types like `long' and just plain `int' in an interface!
Depending on what you're trying to do, int or long int may well be the more portable choice. Using (for example) int32_t renders the code nonportable to systems that don't _have_ 32-bit integers - and slow on systems that don't have them in hardware but fake it in software for the sake of all the code that blindly assumes there is such a type. Of course, if you really do want "thirty-two bit integer", yes, do that. But if you just want a small integer, and it doesn't need to get passed around between machines? Then use int. As an example, consider file descriptors. Consider storing the length of a command-line argument. Consider looping over board coordinates in a program dealing with a game such as chess or go. Consider handling widow widths or heights, in pixels. There are lots of use cases where int is a significantly better choice. In fuse's case? I don't know fuse enough to know which types make more sense for the two struct elements in question. But I don't think that using fixed-size types like int32_t is automatically the rightest answer. Neither is automatically using machine-sized types like int. The right answer is thought based on the kinds of portability that matter for the interface in question. It's possible that in fuse's case, int32_t is actually the right answer. But the quote above looks more like a reflex reaction than a considered opinion, and - at least as far as what got posted goes - whatever it is, it is not backed up with any justifications. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
