Subject: Re: [PATCH] Do not use sized constants in public headers

Re: [PATCH] Do not use sized constants in public headers

From: Yang Tse <yangsita_at_gmail.com>
Date: Thu, 17 Jun 2010 01:47:01 +0200

2010/6/16, Jakub Hrozek wrote:

> But it seems that the CARES_SIZEOF_ARES_SOCKLEN_T and
> CARES_CONFIGURE_LONG are only used for check that the configure time
> constant equals to the build time constant.

No. It is used as a compilation time assert, to verify that the size
of a data type at c-ares build time (or configure) is the same as when
library is finally used. To prevent the unsuspecting user from
shooting his own feet.

> It is used nowhere in the
> actual code, therefore my proposal (also backed by Daniel's in the
> referenced bug) to remove them, at least from public headers into some
> private part of code if not completely.

In current repository state it might be true that there is no further
use besides the already mentioned one.

There are plans in my personal TODO list to further improve current
check, expanding it so that additionally a runtime check is performed
at library initialization. This would make the check even more useful.

I have not found yet a period of time to afford this. On the other
hand July seems will give me some spare time that I could probably use
for this. But take no promise here.

2010/6/16, Daniel Stenberg <daniel_at_haxx.se>:

> Yes, there seems to be no point to add this burden to users of c-ares
> unless we actually have a reason to, and with these defines that aren't used
> by the public c-ares API I think we can just remove them for now, or
> possibly make them private.
>
> If we figure out a reason in the future why we need them there, we can
> always put them back then.

I've already expressed above my _intended_ plans. These would most
probably require existing stuff reintroduced if it is now removed.
Reintroducing it will be easy, but the inconvenience for packagers
will be equally back (most probably).

It's your decision if you want to remove this now, Daniel.

-- 
-=[Yang]=-
Received on 2010-06-17