Skip to Content.
Sympa Menu

freetds - Re: Patches

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: Patches
  • Date: Thu, 27 Jun 2002 15:11:45 -0400


> From: Sam Denton [mailto:denton AT wantec.com]
> Sent: June 27, 2002 1:14 PM
>
> Here's my suggestion (and James, you had a semi-colon problem
> that I've also fixed):
>
> #ifdef _REENTRANT
> /*
> * Requires "THREAD_SAFE_BUFFER" appear
> * among caller's automatic variables
> */
> # define THREAD_SAFE_BUFFER struct tm tsb_tm /* et. al. */
> # define localtime(x) localtime_r(x, &tsb_tm)
> #else
> /*
> * Appearance of "THREAD_SAFE_BUFFER"
> * among caller's automatic variables
> * has no effect.
> */
> # define THREAD_SAFE_BUFFER 0
> #endif

Sam,

Very nice, less is less. I hope Brian agrees. If he does, would you put
together a patch? I don't see why it couldn't be included in 0.60, except
that feeping creaturism leads to delays. If we don't have a release pretty
darn soon, I'm going to start holding my breath!

Another idea, not as good but less work, would be to turn your solution on
its head. Instead of redefining localtime(), we could redefine
localtime_r(), throwing away the second parameter #ifndef _REENTRANT. It's
less work because we could use Stan's patch intact, modifying just one
header file in addition (instead of going through the output of your script
looking for places to define a THREAD_SAFE_BUFFER). It's not as good
because it doesn't prevent someone from adding a call to localtime() later,
breaking threadsafeness in the process.

Do you happen to know what governs whether or not _REENTRANT is defined? Is
that something that's supposed be controlled by ./configure? It can't be
something you just happen to define (or not) in your application's header
file, because it would be a compile-time choice for libtds.

Regards,

--jkl

P. S. Including the semicolon was intentional, BTW. I had in mind you'd
have:

function()
{
THREAD_SAFE_BUFFER
vars;
...
}

with no semicolon necessary. Maybe it's too clever by half, but that was
the idea.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page