cURL / Mailing Lists / curl-library / Single Mail


Re: cURL 7.19.7 v. VMS

From: Steven M. Schweda <>
Date: Tue, 29 Dec 2009 13:29:32 -0600 (CST)

From: Yang Tse <>

> >
> 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)
      # 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:
Received on 2009-12-29