Hi Bruno, Am Mi., 16. Juli 2025 um 14:20 Uhr schrieb Bruno Haible <br...@clisp.org>:
[...] > > 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. > > The difference does matter. If something is merely a pointer, the > programmer can pass it down to other functions by value. Whereas passing > a 'struct string_buffer' by value would 1) have terrible performance, > 2) not achieve the intent that the callee's effects are visible > in the caller. I usually take a look at the API (does it pass by value or reference) and, of course, also at the code (because for a structure made from two words it can make a lot of sense to pass it by value - if the API supports it). My main point, however, was more about the consistency; gl_list_iterator_t, for example, hides a quite large structure. Of course, your remark about the number of uses can be applied here as well. It is less clear with, say, Hash_tuning from the module hash. > So far, you haven't been convincing me. The point is not too important, of course. Consider it as a nudge from a Gnulib user. > > 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.) > > I have no personal recommendations on this one. Maybe you will like the > ones from the prior knowledge summarization engine (attached)? I was more thinking of guidelines tailored to the Gnulib codebase. Marc
