curl-library
Re: Allow compiler typechecking for CURL, CURLM and CURLSH
Date: Tue, 21 Jun 2016 14:45:02 +0200 (CEST)
On Tue, 21 Jun 2016, Reinhard Max wrote:
> I found that this has been discussed already back in 2007 and Daniel seemed
> to be positive about it, but then the discussion ended without a visible
> decision one way or the other, so I am picking this up again.
Oh man, that's an old goldie. But thanks for digging it up and moving it back
into the daylight.
> I changed the definition of these types to be opaque structures:
>
> typedef struct CURL CURL;
> typedef struct CURLM CURLM;
> typedef struct CURLSH CURLSH;
> Using dummy names has the advantage of not revealing additional details
> about libcurl internals, but people can read the source code anyway, so it
> doesn't really hide anyting. I think using the internal names would have the
> advantage of extending the typechecking into libcurl itself, because
> functions that take one of these types would not need an explicit cast to
> the internal type, but I haven't checked this thoroughly.
Using fake names has the obvious downside that it will require changes to
libcurl code which at points actually passes in pointers to the real structs
and not using the typedef'ed void pointers.
By using the real struct names it becomes a much smaller change - with no
impact on the libcurl code at all. See attachment for a patch that does this.
My only minor concern with this patch is if we should take the opportunity and
rename the SessionHandle struct before we hang it out on public display like
this...
-- / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
- text/x-diff attachment: 0001-headers-forward-declare-CURL-CURLM-and-CURLSH-as-str.patch