cURL / Mailing Lists / curl-library / Single Mail


Re: cURL 7.19.7 v. VMS

From: Steven M. Schweda <>
Date: Tue, 29 Dec 2009 21:12:15 -0600 (CST)

From: Daniel Stenberg <>

> The current variable size cleanup effort was made to make sure that apps and
> libcurl work the same way no matter what size off_t is said to use. libcurl is
> no longer depending on off_t nor which size off_t has.

   Ok. If you're not actually using fseeko()/ftello(), where off_t is
significant, then it probably matters little whether
CURL_TYPEOF_CURL_OFF_T is related closely to the real off_t (making it,
perhaps, an odd naming choice), and, similarly, the definition of
_LARGEFILE (or lack thereof) may also be unimportant.

   If no one actually uses any functions which rely on a known 32- or
64-bit size for off_t, then it might make sense to rip out the code in
the builder related to _LARGEFILE.

> # if defined(__alpha) || defined(__ia64)

   This would still make more sense as
        # if !defined(__VAX)
unless anyone seriously thinks that any future VMS platform is more
likely to look like a VAX than like one of the newer architectures.

From: Marty Kuhrt <>

> I never had problems with the builds on ODS5. I built it on VAX, Alpha
> and IA64 from the same disk/dir.

   Well, as I explained (in private e-mail) back in February, that was
probably because you first unpacked the kit onto an ODS2 disk, which
would up-case everything, and then copied the up-cased stuff to an ODS5
disk. When the original kit is unpacked onto an ODS5 disk, you can get
directories like, say,
and this causes trouble for (lame) DCL, like:
      $ thisdir = f$parse( proc,,,"DIRECTORY") - ".PACKAGES.VMS]"
because there is no ".PACKAGES.VMS]" in ".packages.vms]". Hence:

ALP $ @ [.packages.vms]
%DCL-W-PARMDEL, invalid parameter delimiter - check use of special
%DCL-W-PARMDEL, invalid parameter delimiter - check use of special
%DCL-W-PARMDEL, invalid parameter delimiter - check use of special

> The DECC$SYSTEM_INCLUDE logical was done because a while back the cURL
> maintainers had made some incorrect assumptions about which way includes
> should be done. They may have fixed it. Since it built fine, I didn't
> change it.

   And if cURL were the only thing I ever built, then I might not be
bothered by a persistent (and silent) change to the way the C compiler
operates. But it's not.

> To each his own. I find defining things in DCL easier to work with and
> change that having to do all that changing the C code nonsense. You
> change it, you maintain it.

   I don't mind defining things in DCL, just to making trouble more
widely than necessary. I thought that my C-code changes were pretty
limited (and getting more so, apparently).


   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-30