Re: Conflicting fuse_opt.h
On Mon, Mar 28, 2022 at 09:03:07AM -0400, Mouse wrote: > > 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. true. I stated this because from what I read it was supposed to be an interface between modules in/to fuse. Software written by different authors on different systems who all might take different assumptions on its width. Thats all really :) Reinoud
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 HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Conflicting fuse_opt.h
Hi,
On Wed, Mar 23, 2022 at 02:28:39PM +, Emmanuel Dreyfus wrote:
> I am almost certain I already raised that question, but I could not find
> where, and the issue remains to be fixed.
>
> NetBSD's src/lib/librefuse/fuse_opt.h
> struct fuse_opt {
> const char *templ;
> int32_t offset;
> int32_t value;
> };
>
> libfuse's https://github.com/libfuse/libfuse/blob/master/include/fuse_opt.h
> defines (comment striped for the sake of clarity):
> struct fuse_opt {
> const char *templ;
> unsigned long offset;
> int value;
> };
>
> That is fine on IPL32 but breaks on LP64, especially when a program used
> one header, and a plugin used another. But how should that be fixed? If
> I fix NetBSD's version, I will certainly break some software that used
> the old header and link with a new library.
If you want portable code, i'd refrain from using underspecified types like
`long' and just plain `int' in an interface! But that aside...
If the programs and the plugins are compiled on NetBSD, will they still see
the `orginal' header file? Or do you suspect that they might have their own
copies around that break on linking?
Reinoud
