"_t" type names, and other coding style alternatives

[Ivan Shmakov]

>>>>> Nikos Mavrogiannopoulos <address@hidden> writes:
>>>>> On 10/08/2012 09:16 PM, Ivan Shmakov wrote:
>>>>> Nikos Mavrogiannopoulos <address@hidden> writes:

[…]

 >>> -  ASN1_ARRAY_TYPE -> asn_static_node_t
 >>> -  ASN1_TYPE -> asn_node_t
 >>> +  ASN1_DATA_NODE -> asn1_data_node_st
 >>> +  ASN1_ARRAY_TYPE -> asn1_static_node_t
 >>> +  ASN1_TYPE -> asn1_node_t

 >> AIUI, the use of the “_t” type name suffix is generally discouraged
 >> (for names other than those of POSIX own types, and types provided
 >> by vendor-specific POSIX extensions; see below.)

 > Then, I think that I'll use the _p instead.

        There isn't a formal standard reserving those, but there's a
        convention of using _p for “predicates” (both boolean variables,
        like done_p; and boolean functions, like writable_p (fp).)

        Thus, it may be better to use _ptr or _pt instead.

 > Any better suggestions?  (I don't like a plain name because it does
 > not distinguish a type from a variable)

        And why not?

        The reason behind _t was to provide a safe namespace for POSIX
        extensions (essentially the same reason as that for the asn1_
        prefix.)  OTOH, there's a wide variety of C standard types that
        don't bear _t, like double, or FILE *.  So, asn1_node seems
        quite natural to me.  (Although if both struct and pointer types
        are used, a specific suffix to discern one from another does
        make sense.)

        As for the structures, I feel it somewhat uncommon for the
        struct name and the corresponding type name to coincide (as in:
        typedef struct foo foo;.)  Rather (and [1] also speaks in favor
        of that), the struct names are spelled explicitly, like:

-  typedef struct asn1_node_st asn1_node_st;

   extern ASN1_API int
-    asn1_read_node_value (asn1_node_t node, asn1_data_node_st* data);
+    asn1_read_node_value (asn1_node_pt node, struct asn1_data_node *data);

        (Although it's longer, an explicit struct also gives more
        clarity than the non-conventional _st suffix.)

        Also to note is that, contrary to the other type modifiers (such
        as, e. g., unsigned or const), * “sticks to the right.”  Cf.:

    /* this:             is the same as: */
    unsigned int a, b;      unsigned int a;
                            unsigned int b;

    /* but this:         is /not/ the same as: */
    FILE* f, g;             FILE *f;
                            FILE *g;
    /*                   instead, it's the same as: */
                            FILE *f;
                            FILE  g;    /* note missing * */

        So, there's a convention of placing whitespace before *, not
        after.

[1] http://www.eyrie.org/~eagle/notes/style/c.html

-- 
FSF associate member #7257