help-libtasn1
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Josefsson
Subject: Re: "_t" type names, and other coding style alternatives
Date: Tue, 16 Oct 2012 09:45:44 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux)

Ivan Shmakov <address@hidden> writes:

>>>>>> Simon Josefsson <address@hidden> writes:
>>>>>> Nikos Mavrogiannopoulos <address@hidden> writes:
>
> […]
>
>  >> The problem is that we need to have source compatibility.
>
>  > We don't have that since we are removing some internal structs..
>
>       ?  The applications' source code isn't expected to refer to the
>       internals.

The structs were exported in libtasn1.h, for 3.0 we are removing them.
So any code out there that relies on these structs will break due to
source level incompatibility.  This will be rare (GnuTLS used it only in
one place) and possible to fix (using the new asn1_read_node_value())
though.  Changing the basic types without backwards compatibility hooks
will break all applications though, so that is not an option -- my point
was that instead of changing the basic types and adding backwards
compatibility hooks, we could also live with the old names that are in
the right namespace.  While asn1_node and asn1_data_node_st look nicer
than ASN1_TYPE and ASN1_DATA_NODE I'm not sure changing them is worth
the costs of having all applications out there change their code, even
if ASN1_TYPE and ASN1_DATA_NODE will continue to work for some time.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]