Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows

[Bruno Haible]

Simon Josefsson wrote:
> I have considered the '_t' suffix for types philosophically related to
> hungarian notion (and thus avoided it).  What are the opinions on
> using 'foo_t' or 'foo' for new typedef's in a library?

I'd recommend using the suffix _t because
  a) It makes it easier for the user to distinguish variable declarations
     and statements _without_ having to learn by heart the complete list
     of types that a package define. This is becoming more important these
     days, when more and more projects assume C99 or C++, where declarations
     can occur anywhere in the code, not only at the beginning of a block
     or function.
  b) Emacs syntax coloring works better with it.
  c) The "possible collision with system types" argument is a theoretic one
     not relevant in practice (unless you attempt to define uint16_t).

> Another option I have considered is to not use typedef at all, but
> rather write 'struct foo *foo' instead of 'foo *foo' or 'foo_t *foo'.
> (I got that idea from GNU lsh.)

That's ok in some cases. 'foo_t' allows to hide details: When I write
'lex_pos_t position', I don't care whether lex_pos_t is a struct containing
a line number and a column number, or a plain 'int' containing just a byte
number. And it may evolve from 'int' to 'struct' without forcing me to
update all references in the source.

Bruno