From: Daniel Stenberg <daniel_at_haxx.se>

> 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 <marty_at_spamloop.kuhrt.net>

> 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,
      ALP$DKA100:[UTILITY.SOURCE.curl.curl-7^.19^.7.packages.vms]
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]build_vms.com
%DCL-W-PARMDEL, invalid parameter delimiter - check use of special
characters
 \]\
%DCL-W-PARMDEL, invalid parameter delimiter - check use of special
characters
 \]\
%DCL-W-PARMDEL, invalid parameter delimiter - check use of special
characters
 \]\
[...]

> 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: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-12-30