On 2015-11-24 09:06, Daniel Stenberg wrote:
> On Tue, 24 Nov 2015, Michael Felt wrote:
>
>>> If someone has a good idea of how to tweak libcurl to make this
>>> process easier or more streamlined in any way, please let me know.
>>>
>> I have not been concerned with things like this for a long long time.
>> The obvious solution path, imho, would be to not make myself
>> dependent on the sizeof(long) - as this is variable.
>
Stress - a very very long time. Back when C++ was more a C
pre-processor, and I used C as a high-level assembly language (i.e.,
compile to assembly and then edit/optimize) - almost long ago that could
miss it. But not quite that long ago :p

> If the size of 'long' is a variable, then so is every other thing we
> check for in the configure script. That's the reason ẃe check for
> them! To figure out the situation for your system and adapt to that.
>
nods!
> I understand that it is tempting to just throw oneself at this problem
> and offer some grand simple solutions - but if you don't properly take
> time to research the problems and perhaps their history in curl,
> you're just going to fall into some of the same traps we were in before.
>
See above - long time ago. And I hoped I was honest enough that I did
not want to assume there is a quick fix. You earlier statement was clear
that it was complex aka not simple.
> It often goes back to the fact that we have rather aggressive
> portability ambitions.
I am just a simple packager - and I love portability - which is why I
posted anything at all. As far as your ambitions go, my feedback is just
feedback. I shall try and think of how to warn people that there are two
libraries and two sets of include files. While it is normal, rather
necessary, to have two shared libraries, one for each binary mode - I
have hoped for one set of include files.
>
>> The struct could always be a typedef as "long long" - which at least
>> until know has been 8 bytes in both 32 and 64 bit.
>
> Nopes. That is incorrect on several ways: The first and most basic
> problem: not all systems and compilers have long long. The second
> would be that not all systems that have 64 bit types like "long long"
> for their 64 bit type. So no, we can't do it like that.
>
I bow to your experience. Me being silly - rather naive - hoping it
could be so simple. Maybe there are other errors I have not seen because
make stops at the first error. If it was only this in the innclude file
- oh - I was so hoping it could be coded easily such that one include
file would serve two binary environments.
> One of our legacy choices from way back is that we're using C varargs
> at several places and then we MUST make sure that the library and the
> application agree on variable sizes since there's no automatic
> variable conversion in the same way that otherwise the C language
> provides.
I have never used varargs - so excuse me for not understanding a word.
Is this dynamic/runtime discovery?
>
> The perhaps biggest quirk is how we handle file sizes larger than 32
> bits on 32 bits systems and which variable type and how you use that
> so that we can have the same type for all systems. We use curl_off_t,
> but we had a somewhat bumpy road before we ended up with this
> solution. A road that lead to quite a few users having their
> application and libcurl disagreeing on how big that curl_off_t type
> was. It caused tears and upset users.
For large files -maybe there is a standard way to handle this now. I
know that AIX has a define _LARGE_FILES that triggers an additional
define _LARGE_FILES_API and also redefines several typedef _t types to
fit that model. It is default in 64-bit mode (if I recall correctly) and
optional in 32-bit mode.

Not today - but certainly down the road. If you have the patience to
deal with my simple questioning - as I have no desire to modify any
(design) decisions made in that past - I will try to find time to go
deeper. I think CURL is one of the projects that has caught my eye.
>
>
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-11-25