Skip to Content.
Sympa Menu

freetds - RE: Non portable code

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Jonas Benjaminsson" <jonas.benjaminsson AT infogate.se>
  • To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
  • Subject: RE: Non portable code
  • Date: Wed, 2 Oct 2002 17:05:10 +0200


:: As Brian said, it's best to post your "diff -ru" output to the sourceforge
:: patches page. If you've got CVS functioning, it's a good idea to keep your
:: tree up to date. Just let "cvs update" merge changes to the base into your
:: workfiles. That way, your patch can be cleanly applied when you send it,
:: and you won't wind up fixing something that becomes obsolete.

I will do that.

:: Slow is better than broken.
::
:: Speed is not an issue here, really, because the client CPU is so much
faster
:: than data transfer to the database. In any case, writing the null device
:: sure oughta be fast, and any algorithm that could determine the right
:: allocation size would have to do something a lot like what vfprintf(3)
does.

I agree.

::
::
:: Wouldn't this be portable?:
::
:: #ifdef WIN32
:: #define TDS_NULL "NUL:"
:: #else
:: #define TDS_NULL "/dev/null"
:: #endif
:: ...
:: if ((fp = fopen(TDS_NULL, "w")) == NULL)

You're so right, it sure did work.

:: Besides, Win32 OS's ship with a vfprintf(), so you don't really have to
:: worry about compiling or using the replacement.

Yes it does, and that's what I'm going to use.
Just thought the aproach to write to a file was somewhat odd.

:: Lucka till med din project, and regards,

Tack! :-)


/Jonas





Archive powered by MHonArc 2.6.24.

Top of Page