Re: "_t" type names, and other coding style alternatives

[Nikos Mavrogiannopoulos]

On Thu, Oct 11, 2012 at 2:22 PM, Simon Josefsson <address@hidden> wrote:

>> Didn't like any of those. I just dropped the _t.
> I also prefer just dropping any suffix.
> Btw, is the "compatibility types" section really needed?  The reason for
> the 3.0 branch was that we wanted to drop old compatibility code...

The problem is that we need to have source compatibility. If we force
everyone to update their programs just to use 3.0 then adoption will
be slow. Having a define of the old type to the new name is not much
of an issue.

>it seems bad to introduce _new_ compatibility code now.  I think at least
> the 'node_asn' and 'node_data_struct' types should be dropped since
> there is a namespace violation.

They exist in the 2.x series and that means compilation errors. I'd
prefer to keep source code compatibility even if we break the binary
one.

> Thinking about this, I'm not sure it is worth the effort to move from
> 'asn1_node_t' to 'asn1_node'.  It will require a large effort for
> everyone who uses libtasn1 to adapt, and for purely a cosmetic gain.

The move is from ASN1_TYPE -> asn1_node (the asn1_node_t was an
intermediate name). Since the old values will be available I don't
think this will be much of an issue. New programs will be clear and
have more consistent type names.

regards,
Nikos