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
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index