Hi Bruno, Am Di., 15. Juli 2025 um 18:20 Uhr schrieb Bruno Haible <br...@clisp.org>: > > Hi Marc, > > > Many if not the majority of Gnulib modules provide typedefs for the > > public structs they export (*). It just occurred to me that the > > (x)string-buffer module does not provide any typedef for its struct > > string_buffer. > > > > Was this an oversight or on purpose? > > What would be the benefit? > > typedefs are usually used to hide implementation details, for example > 'u64' may be a struct or an integer type. Or, some libraries define > typedef struct foo foo_t[1]; > when they want a type that is not copied when passed through a function > call. > > When the API contains a struct type, the programmer knows exactly what > happens in function calls and whether to pass a pointer. > > The only benefit that I see is that the typedef name is usually shorter > to write. But that does not matter when, typically, there will be 1 or > at most 2 instances of such a struct in a given function.
The related module string-desc exports the typedefs string_desc_t and rw_string_desc_t, although the structure is also part of the public interface in the sense that it is not only accessed through a pointer by user code. It would at least have the benefit of consistency to have a typedef for string_buffer as well. (What is not so consistent is that the struct name of string-desc has a "_t" suffix, which looks, at least, unusual to me - but maybe this is common in Gnulib.) As the user is not supposed to touch the structure fields directly, the struct string_buffer type should be considered opaque in my opinion; it should not matter for the user whether it is implemented as a struct, a union, or as a pointer to some heap-allocated data. A typedef would abstract away from a particular struct representation. Certainly, it is not a major point to have a typedef, but some consistency guidelines (if possible) for future developments would be nice (e.g., when to typedef or not, how to name a struct/typedef, whether to typedef away a pointer or not, etc.) In the existing code base, many approaches seem to have been tried. Of course, every such general rule cannot be more than this; particular cases may need other solutions. Thanks for reading, Marc > > Bruno > > >
