FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

At 10:23 AM -0500 1/27/03, Lowden, James K wrote:
> > From: Craig A. Berry [mailto:craigberry AT mac.com]
> > Sent: January 26, 2003 7:25 PM
>
>If I ever get VMS installed on my VAX (hobby media have been sold out for a
>while), I'd like to try to build your port. 

Thanks.  Supposedly they will start shipping the updated VAX hobbyist
kits any day now:

<http://www.montagar.com/hobbyist/mount.html>

I'm doing my development on Alpha and I'm not 100% sure FreeTDS will
work on VAX.  I've currently hard-coded IEEE floating point into the
build, but G_FLOAT (which is available on VAX) might work too,
assuming the TDS protocol never puts binary floating point data on
the wire.  I'll have to think about whether there are any other
VAX-unfriendly assumptions I'm making; I don't have any VAXen to test
on myself.

>Do you intend to send us
>patches, so future versions will Just Work? 

Yes, the patch will consist of a handful of new files that will all
go under a new "vms/" directory.  Outside of that I haven't needed
any other changes except for the replacements issue that seems to
have raised hackles.  Whether it "will Just Work" depends on a number
of things.  Unfortunately it's not possible to use the unixy
configuration process so what you'll get is a hand-coded Makefile that
will need to be updated whenever the names and number of the .c and
.h files change.  Once that stabilizes, though (if it hasn't
already), the build will certainly pick up whatever bug fixes come
along.

>I'm not that keen on your patch.  In a unixy system, the configure script
>detects the availability of those functions, and generates a Makefile for
>the replacement library that excludes system-provided functions.  IOW, on a
>system requiring no replacements, that library would be empty. 

There is no configure script on VMS and the Makefile is not
generated.  The build does detect various things about its
environment and creates certain include files on the fly.  It might
be possible, though it would almost certainly be messy, for the
Makefile to detect the version of the C run-time and build whatever
replacement functions it needs based on that.  That would cover some,
but not all, of the problems that arise from having home-grown
functions with the same names as standard (or at least common) C
functions.  It's a lot easier, and solves more problems, to let the
compiler use its knowledge of the C run-time version and select the
replacements needed based on that.

This line in my config.h template:

#define HAVE_STRTOK_R (__CRTL_VER >= 70301000)

in combination with the patch I submitted means that I get the
system-supplied strtok_r when it exists and only see the home-grown
one when I need it.  The freetds_strtok_r is latent in the library;
it doesn't violate the C library's namespace on systems that don't
need it but it is always available for systems that do. 

>It sounds like even on VMS, you don't run into trouble unless you upgrade
>the OS and rebuild FreeTDS without regenerating its makefiles.  Why would
>you do that? 

Even (and perhaps especially) if I don't rebuild FreeTDS there will
still be a problem because there will be, for example, an strtok_r
symbol in one of the package's object libraries that will collide
with a new system-supplied function when I link against it.  Don't
unix systems supply object libraries that are expected to work across
multiple OS versions?  It's quite routine on VMS.

A scenario may help clarify one of the potential problems:  some
hypothetical developer distributes a set of FreeTDS object libraries
in binary and explicitly states that they will work on VMS 7.1 and
later.  A hypothetical COBOL programmer installs these on his 7.2
system, confident they will work because his system meets the minimum
OS version requirement.  He has to muck about a bit and convert the
.h files to his own COBOL include files, and he has to concoct
null-terminated strings to call C functions, but both of these are
pretty trivial.  Soon he is off and running and developing an
application that uses one of the FreeTDS interfaces.  This COBOL
programmer has never heard of autoconf and does not have a C compiler
installed on his system, though he does have the C run-time because
that's part of the OS.  One day he upgrades his OS to 7.3-1.  The
next time he builds his application, the link dies with a multiply
defined symbol error.  When he figures out it is one of the FreeTDS
libraries that is not upward compatible he will rightly consider it
broken.  He can probably work around it by deleting the offending
module from the library, but that's a hack that shouldn't be
necessary.

I guess the moral of the story is all of the things that should not
be assumed: autoconf, Configure, source distribution, and C, for starters.

>In general and all other things equal, the less the preprocessor munges the
>source code, the better.  Granted, you're adding just one level of
>indirection, but it's on top of a few others.  Before I'd apply your patch,
>I'd need to be convinced it's really necessary and is a complete answer.

OK, well clearly I've spent too much time poring over the Perl
sources and they've corrupted my thinking about C macros ;-).  I'm
not sure I quite get why what I've proposed is considered
preprocessor abuse, but I do want to do the right thing.  I just
haven't yet thought of a different way of getting what I need.

>Meaning: rebuilding without reconfiguring after upgrading the underlying
>system is fraught with trouble, trouble easily avoided by reconfiguring.
>(Too many gerunds, Sire.)  If it's really necessary or helpful to rebuild
>without reconfiguring on VMS, and this technique addresses all related
>difficulties, I'd go along with it. 
>
>I hope that sounds reasonable to you.  If I misunderstood something, please
>correct me. 

Thanks for listening and for explaining your concerns.  If no one
proposes a better solution I guess I can create edited-on-the-fly
versions of the replacement functions for VMS.
-- 
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser