On Mon, 30 Jul 2007, Dan Fandrich wrote:

> My only objection is that it forces all option strings to be treated
> strangely and differently compared to other option data

I agree that it changes things around, not necessarily in a good way.

But then I also think that since these strings are now duplicated, it makes a
little sense to "collect" them logically.

So I still think this approach is the better way even with its drawbacks, when
we start allocating the strings.

> Putting the strings into a union something like:
>
> union {
> struct str {
> char *device;
> char *set_referer;
> char *useragent;
> ...
> } str;
> char *allstrings[sizeof(struct str)/sizeof(char *)];
> } strs;
>
> solves this half way, allowing access with data->set.strs.str.device while
> still allowing access through an array, so even if it's portable it's still
> a bit ugly.

My recollection of the ANSI C documentation (although admittedly it was some
years ago since I read them), is that the above approach is _not_ portable
(although still working on most platforms).

Not that it matters greatly since that is quite hideous looking as well. Also,
using unorthodox ideas in code is not a good idea when lots of people are
supposed to be reading and understanding the code, both today and in the
future.

> I suppose the string array will have to do. Here are a few minor things I
> spotted in that patch.

Great! I'll adapt.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html