[Libwebsockets] API change / no feature test

Andy Green andy at warmcat.com
Wed Sep 3 03:15:54 CEST 2014



On 3 September 2014 05:48:49 GMT+08:00, Roger Light <roger at atchoo.org> wrote:
>Hi Andy,
>
>The trouble is that the examples don't do that, so changing the public
>struct has a very good chance of breaking every single piece of
>libwebsockets code out there.

Well, for some reason I thought this was struct info, which is done in the samples by dynamic allocation + memset.

But it's protocols, in the samples this is done by an oldstyle static initializer to support Windows compiler, for whom C99 is still 'too new'.

Considering "breaking every single piece of lws code out there" how do you figure that?

In terms of breaking things, adding the id member itself broke the abi for that struct necessitating a recompile, and we did an soname bump.  And nothing in lws uses the id member.  So far there's no lws release version since then so we're still "in development".

Comparing from the last release, with the id member taking the place of this deleted member, old code does not use the id member, and the deleted member is, well, deleted and had no effect anyway.

Have I still missed the point about the sky falling?

-Andy

>Cheers,
>
>Roger
>On Sep 1, 2014 11:30 PM, "Andy Green" <andy at warmcat.com> wrote:
>
>>
>>
>> On 2 September 2014 03:24:41 GMT+08:00, Michael Haberler <
>> mail17 at mah.priv.at> wrote:
>> >Hi Andy,
>> >
>> >the libwebsocket_protocols struct changed in
>> >
>>
>https://github.com/warmcat/libwebsockets/commit/822241c2a79d05c535dc2c7415fd8345ee72b7fb
>> >
>> >unfortunately this changes the position of the id field, and hence
>> >breaks its initialisation:
>> >
>> >- *             got send yourself.
>> >* @id:                ignored by lws, but useful to contain user
>> >information bound
>> >*             to the selected protocol.  For example if this
>protocol
>> >was
>> >*             called "myprotocol-v2", you might set id to 2, and the
>> >user
>> >@@ -890,7 +882,6 @@ struct libwebsocket_protocols {
>> >        callback_function *callback;
>> >        size_t per_session_data_size;
>> >        size_t rx_buffer_size;
>> >-       int no_buffer_all_partial_tx;
>> >        unsigned int id;
>> >
>> >
>> >
>> >I guess we need a feature test in one way or the other to make
>existing
>> >using code compile?
>>
>> It should be fine using either
>>
>>  - dynamic struct alloc like info: memset the struct to 0 and set the
>> members you cared about
>>
>>  - static struct alloc: use C99-style static struct initializer
>(.member =
>> value)
>>
>> This removed member isn't one the code should care about, its
>function was
>> broken for a long time and it should be fine to leave it at 0.
>>
>> If there is someone who needs it at 1, yes, the feature flag would be
>> needed.  But for 0, one of the above methods will do it if it exists
>and
>> not break if it doesn't.
>>
>> -Andy
>>
>> >- Michael
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >Libwebsockets mailing list
>> >Libwebsockets at ml.libwebsockets.org
>> >http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
>>
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
>>




More information about the Libwebsockets mailing list