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

[Simon Josefsson]

Thanks for your opinions.

Bruno Haible <address@hidden> writes:

> 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.

I agree with these.

>   c) The "possible collision with system types" argument is a theoretic one
>      not relevant in practice (unless you attempt to define uint16_t).

If the standard really do use strong wording that application writers
must never introduce '_t' types, I'm somewhat reluctant to use it,
even though it is an academic argument.  Perhaps I could rationalize
using it by considering the library I write a "system library"
containing "system types".  If the standard merely give a warning, I
see no problem and will probably start to use it.

>> 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.

Right.  In my case, however, I'm only considering using 'struct foo*'
for things that are very unlikely to ever become anything else (such
as a library context handle).