Skip to Content.
Sympa Menu

freetds - RE: convert.c and the next release

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: convert.c and the next release
  • Date: Mon, 5 Aug 2002 10:27:57 -0400

> From: Varley, David(CBorn at Alcoa) [mailto:David.Varley AT alcoa.com.au]
> Sent: August 4, 2002 9:57 PM
>
> Your addition of the HAVE_ATOLL test lets me compile on the
> alpha system.
> In testing I found another problem with the long long usage
> there though,
> in that printf("%lld",ll); will just print "ld", ie the format string
> does not allow the %lld form, rather just printf("%ld",ll);
> will work and
> print the 64 bit int. As %lld is used twice in convert.c, I
> guess they both need the conditional compilation too.

I'll take care of that. Thanks for the feedback.

> I also tried to configure those latest changes on x86 Linux,
> and found that
> the #undef HAVE_ATOLL is commented out in config.h, although not in
> config.h.in,
> and so convert.c tries to use your static atoll() and fails
> to compile due
> to conflicting types. Don't know why, is it just me ?

Worked for me. But to make it work, I had to do a 'make clean' and I re-ran
autogen.sh. I think your Linux box has a working set of cached
configuration data, causing configure to skip something it shouldn't.

> At present on the alpha all the unit tests pass except for 4,
> which returns
> TDS_FAIL on tds_process_result_tokens()

That's good.

> Oh, and your link
> http://home.schemamania.org/freetds/cvs/freetds/src/dblib/unit
> tests/convert_acid.c
> returns FORBIDDEN when I try to access it.

Sorry, my bad; I'll fix that tonight. The file is attached.

--jkl

> -----Original Message-----
> From: James K. Lowden [mailto:jklowden AT speakeasy.org]
> Sent: Monday, 5 August 2002 9:08 AM
> To: TDS Development Group
> Cc: David.Varley AT alcoa.com.au
> Subject: [freetds] RE: convert.c and the next release
>
>
> On Sun, 4 Aug 2002 21:49:08 +0800, "Varley, David(CBorn at Alcoa)"
> <David.Varley AT alcoa.com.au> wrote:
>
> > Regarding the atoll() problem, a long is 64 bits on the
> alpha anyway,
> > and atol() returns a 64 bit int, so atoll() is not required
> or provided.
> > A simple #define atoll atol would fix this, but I'm no
> autoconf guru,
> > and I assume that's the place for a proper fix.
>
> David,
>
> >> As a long-time lurker on this list, I have to break my
> silence on this,
> >> although I hate to do so on a negative note after all the
> great work
> >> Bill's been doing.
>
> Glad to make your acquaintance.
>
> I just committed a change to configure.in that checks for
> 64-bit ints and
> uses atol() if atoll() is not provided. Please let me know
> if it works
> for you. The configure script should fail to define
> HAVE_ATOLL on your
> system, causing FreeTDS to rely on atol().
>
> Because the NetBSD system I happen to test with is a few years old, it
> lacks both 64-bit ints and atoll(). I'm experimenting with
> it to see if I
> can use it anyway, subject to the limitations imposed by the missing
> features. Partly for that reason, the configure script will
> *not* fail if
> 64-bit integers are unsupported; it is only a warning. I
> want to see if
> FreeTDS can be made to live within such limitations.
> Ideally, it would
> use 32-bit ints if 64 bit aren't available, and call the
> error handler in
> situations where the width was insufficient.
>
> At the moment, however, char<->money is quite broken for me, see next
> message.
>
> Regards,
>
> --jkl
>
> ---
> You are currently subscribed to freetds as:
> [David.Varley AT alcoa.com.au]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
>
> ---
> You are currently subscribed to freetds as: [LowdenJK AT bernstein.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
>


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.




Attachment: eg_handlers.h
Description: Binary data

Attachment: convert_acid.c
Description: Binary data




Archive powered by MHonArc 2.6.24.

Top of Page