FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

vstrbuild.c has nothing to do with portability.  It provides
tds_vstrbuild(), which is used to implement cs_strbuild() and dbstrbuild().
I did it this way to implement the common functionality in one place,
instead of duplicating lots of code between ctlib and dblib.

threadsafe.c should probably be cleaned up.  All of our code has a
requirement to be threadsafe when _REENTRANT is defined.  If it isn't
defined, then the code provided by threadsafe.c isn't threadsafe.  Quite
confusing.

As far as portability is concerned, the mainline code should just use the
non-standard constructs (as long as they are good ones that provide clean
and useful functionality).  Then, for systems that may not have this
function, we drop a replacement function into src/replacements, add it to
src/replacements/Makefile.am, add the name of the module to the
AC_REPLACE_FUNCS() line in configure.in, and we're done.  No need for messy
unreadable #ifdef contortions throughout the code, and no need for the
programmer to wonder "is tds_strtok_r() really trying to implement the same
thing as strtok_r(), or is there some subtle difference implied by the name
change?" (Speaking of which, I will add a public-domain strtok_r()
implementation later today, and switch over to using that).

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Wednesday, October 02, 2002 9:26 AM
To: TDS Development Group
Subject: [freetds] Re: Non portable code


Hopefully the non-portable code is limited to certain freetds specific 
functions. That is, instead of calling non-portable constructs directly we 
generally make a wrapper function that calls them for us, that way porting 
is limited to ifdef's in the wrapper functions and keeps the mainline code 
clean looking.

We should perhaps combined vstrbuild.c and threadsafe.c into a port.c or 
something similar to make this policy explicit?

As far as diffs go, please post them to the patches section on the 
sourceforge site, unified diff format is preferred.

Cheers,

Brian


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 for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.