curl-library
Re: cURL 7.19.7 v. VMS
Date: Tue, 29 Dec 2009 13:29:32 -0600 (CST)
From: Yang Tse <yangsita_at_gmail.com>
> > http://antinode.info/ftp/curl/curl-7_19_7/curl-7_19_7_s1.dru
>
> I've looked only into the initial part of that patch...
>
> Once more quoting note 2 of curlbuild.h.dist...
> [...]
> So pleas, explain the reasons to absolutely ignore the above and gate
> CURL_TYPEOF_CURL_OFF_T to __off_t in your patch.
Primarily, I couldn't see any reason for the above. All the
underlying I/O functions expect off_t arguments, so what's the point in
trying to find some non-off_t type which exactly matches off_t, when
off_t would seem to do the job perfectly?
It would be ok with me to switch it back to using "long long"
(non-VAX and _LARGEFILE) or "int" (VAX or not _LARGEFILE), so long as
the conditionality looks more like
# if !defined(__VAX) && defined(_LARGEFILE)
than
# if defined(__alpha) || defined(__ia64)
which is simply wrong.
One advantage of using the method I chose is that it pretty well
guarantees that CURL_TYPEOF_CURL_OFF_T is consistent with the actual
type of off_t, or else the compiler will let you know about it. (There
are some basic consistency checks in decc$types.h.) Previous code
(which ignored the _LARGEFILE macro) had no such advantage.
> Can you identify a 64-bit data type on vax-vms?
I believe that there is no atomic 64-bit integer type on VAX.
There's certainly no "long long" there.
------------------------------------------------------------------------
Steven M. Schweda sms_at_antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-12-29