From: Daniel Stenberg <[email protected]>
> 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 <[email protected]>
> 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 s...@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
