tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Conflicting fuse_opt.h
> 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index