FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Craig A. Berry [mailto:craigberry AT mac.com]
> Sent: January 28, 2003 12:38 AM

Craig, 

First of all, thanks for your patient and clear explanation.  I'm glad
you're getting FreeTDS to work on VMS.  "It's not portable until it's
ported", they say.  Conversely, it's portable if it is ported; your efforts
are bound to make the code better.  

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

Indeed, the TDS protocol does put binary floating point data on the wire.
For TDS 5.0, the format is established at login time (see Sybase's "TDS 5.0
Functional Specification", page 175).  The 8-byte format is the IEEE 754
float type, unless it's VAX 'D' or 'ND5000'.  The 4-byte form is labelled
just "IEEE floating point numbers", unless it's "VAX 'F' or 'ND5000'" form.


AFAICT tds_send_login() doesn't set these values correctly.  We log in
anyway, and clearly we get IEEE format floating point data.  I guess we've
been lucky thus far.  And I would be really really surprised if Microsoft's
server ever sent VAX-format data.  

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

Excellent.  

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

I see where you're coming from; it's a reasonable choice.  The replacements
library has some qualities we like, though, so I'd like to explore other
paths.  Please bear with me; if we don't come up with something you agree is
better, your patch at least gives us a workable solution.  Perhaps someone
else following this thread will read our conversation and have an "ah ha!"
moment.  Or maybe it's just a bike shed exercise.  

The notion behind the replacements library is to have a set of public domain
functions to fill holes in substandard C libraries.  That's why the
functions have real names:  they're legitimate implementations of (Posix or
other) standard defined functions.  Nothing tds-specific about them at all.
We leave it to our build tools to pick among the system-provided and
replacements-provided functions, as dictated by the needs of the particular
system in question.  I very much like the public spirit of the replacements
library, and I think it would be good to preserve the names (and
non-freetds-ness).  Granted, that's an aesthetic choice, but when code is
your product, aesthetics matter.  

As a matter of architecture, this is really a link-time issue:  "Whose
strtok() do I link in, and where do I get it from?"  I think it would be
better -- strategically and as a matter of communication to those who come
after -- to solve link-time issues at link time, in the makefile.  I think
that will communicate our purpose better to anyone trying to make the sort
of adjustments you're dealing with.  From the tenor of the your message, I
suspect you agree with me in principle (if not, please say so).  

The question to me becomes: How?  One problem is, the version of the C
library is available to the preprocessor (__CRTL_VER) but not to make, at
least not directly.  That's what tempted us in its direction in the first
place.  What I'd like to do is convey that information somehow to the linker
(and/or to "make" itself) to either:

1.  Avoid adding unneeded functions to libreplacements.a, or
2.  Purge unneeded functions from libreplacements.a

before linking its functions into libsybdb or whatever.  #1 is effectively
what autoconf+automake does (except by direct inspection, not by inference
from the library's version) via the LTLIBOBJS variable.  

Unfortunately, I don't know how to do that, or if it's possible.  :(

You say it would be "messy" even if possible in VMS, and I can well imagine
that to be the case, unless someone pulls a clean solution out of a hat.
After all, autoconf is itself hardly the zenith of elegance.  

The only solution I have atm is not much different from yours: rather than
rename the functions, wrap their entirety in #if HAVE_AUTOCONF ||
!HAVE_STRTOK or whatever.  IOW, "produce this code if autoconf was used or
there's no strtok()".  Unixy systems will always produce the code (insofar
as the preprocessor is concerned) but the makefile will never compile it.
VMS systems will not define HAVE_AUTOCONF, leaving code production to the
HAVE_STRTOK test.  

Your compiler would produce a module with no function;  the linker would
scoop it up but no name would be exported.  That approach would be slightly
better, I assert, because 

1.  the names are preserved
2.  the preprocessor isn't interceding in linkage
3.  the resulting binary is smaller

The unixy systems would be unaffected by this change, except for the
complexity.  

My suggestion does not give the linker or make the information to decide
what to link in; I don't know enough about the VMS tools to do that.  If you
or someone else has a better answer, I am, as Ross Perot said, "all ears".  

Regards, 

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.