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

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Bruno Haible <address@hidden> writes:
>
>> > And I'd omit the trailing '_p' (as I'm not a big fan of Hungarian
>> > notation :-).
>>
>> This isn't hungarian notation, it's the common notation in gnulib
>
> The vast majority of predicates in gnulib do not end in '_p', and I'd
> rather not add new predicates with '_p' suffixes.  The '_p' suffix is
> philosphically related to Hungarian notation.  The basic idea is that
> the type of an identifier should be related to (or deducible from) its
> name.  I'm not a big fan of this idea in general, as it makes names
> longer and less readable, and in the end it tends to detract from
> readability and maintainability.  Admittedly this is a minor issue.

This is not strictly related to gnulib, but since many skilled and
experienced people seemed to be on this list, I'll take my chances:

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?  It is made
sligthtly more complicated than the '_p', or other hungarian notion
issues, because the C language already use '_t', for size_t etc.

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.)  I use 'foo *foo' now, but the Emacs
font locking mechanism appear to work better with 'foo_t *foo' in some
situations (see `c-font-lock-extra-types'), but that hasn't been a
good enough argument to switch for me.  (I would guess it also work
better with 'struct foo *foo' because of the 'struct' keyword.)

Tia,
Simon