cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: cURL 7.19.7 v. VMS

From: Steven M. Schweda <sms_at_antinode.info>
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