Skip to main content.
home | support | download

Back to List Archive

Re: Little bug, some annoying installation details

From: David L Norris <dave(at)not-real.webaugur.com>
Date: Wed Feb 26 2003 - 17:16:26 GMT
On Wed, 2003-02-26 at 11:18, Bill Moseley wrote:
> On 26 Feb 2003, David L Norris wrote:
> 
> > I suspect that was an oversight on my part when I replaced the #ifdef
> > WIN32 with a more general version.  Windows prefixes Standard C
> > functions with _ unless STDC (or something like that) is defined.  It
> > should be safe to remove the _ prefix completely.
> 
> I think it's correct to test for a feature instead of an OS, but it might
> require a bit more testing in the configure script.

Well, configure only tests for sys/timeb.h so it's probably not
perfectly right to begin with.

> Bill Meier replied to me with a bit of research.  It's not entirely clear
> what the correct thing to do is (especially since you build the Windows
> binary on Linux).

On Windows the MSDN docs bundled with MSVC only mention _timeb() and
_ftime().  Only because that's the ANSI naming scheme (which is
conveniently based on Microsoft Xenix).  I think it's a conspiracy to
break compatibility with non-Microsoft systems, myself.  

Anyway, what you do is undefine __STDC__ (thereby disabling ANSI naming)
and all the _ prefixes go away.  (GCC does this by default; or more
accurately never defines __STDC__)  It's not well documented in MSDN but
it's there for every function with a _ prefix in Microsoft's headers. 
And, for Windows builds I use GCC with Microsoft's headers and link to
msvcrt.  GCC works the same on both Windows and Linux.

If you ever want to build on Windows then have a look here:
  http://mingw.sourceforge.net/

> Bill found example code that does this:
> #ifdef _WIN32
> #define FTIME(dummy) _ftime(dummy)
> #define TIMEB _timeb
> #else
> #define FTIME(dummy) ftime(dummy)
> #define TIMEB timeb
> #endif

Hrm, that just doesn't seem like a good thing.  I've found a lot of the
example code and Win32 "workarounds" floating around are based on
assumptions created by not bothering to check the API docs and the C
headers themselves.  ;-)

>From Microsoft's sys/timeb.h:
struct _timeb {
        time_t time;
        unsigned short millitm;
        short timezone;
        short dstflag;
        };
#if !__STDC__
/* Non-ANSI name for compatibility */
struct timeb {
        time_t time;
        unsigned short millitm;
        short timezone;
        short dstflag;
        };
#endif  /* !__STDC__ */

>From sys/timeb.h on my Linux system:
/* Structure returned by the `ftime' function.  */
struct timeb
  {
    time_t time;           /* Seconds since epoch, as from `time'.  */
    unsigned short int millitm; /* Additional milliseconds.  */
    short int timezone;    /* Minutes west of GMT.  */
    short int dstflag;     /* Nonzero if Daylight Savings Time used.  */
  };


> So that might be one option, but not really the "autoconf" way of testing
> for features.

I wouldn't do that.  Besides, we can always fix it later if needed. 

> "The timer class is based in the C function gettimeofday() on POSIX
> systems, the C function _ftime() on MS Visual C++, the C function ftime()
> on Borland C++, and time() on Metrowerks Codewarrior."
> 
> So I'm not sure change to just ftime() wouldn't break things on Windows.

Borland and Metrowerks don't use the Win32 API.  Borland doesn't support
Win32 API at all, AFAICT.

Can you test tomorrow's 2003-02-27 build on Windows?  Builds with no
errors or warnings.  Works fine here under WINE.

-- 
 David Norris
  http://www.webaugur.com/dave/
  ICQ - 412039
Received on Wed Feb 26 17:24:48 2003