[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overf
From: |
Simon Josefsson |
Subject: |
[Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows |
Date: |
Wed, 19 Nov 2003 17:09:53 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) |
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).
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, (continued)
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, James Youngman, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows,
Simon Josefsson <=