Have a more general timestamp implementation.
Very useful for higher accuracy timings.
Modified Files:
simgear/structure/subsystem_mgr.cxx
simgear/structure/subsystem_mgr.hxx
simgear/timing/testtimestamp.cxx simgear/timing/timestamp.cxx
simgear/timing/timestamp.hxx
pun intended) that I'm touching the time library.
Brian Schack reported that the traffic scheduler messes up the timestamps
of the atlas network output. As it turns out, the c library functions
asctime, and gmtime use a static copy of the tm struct to do the internal
formatting. Our linux port of the SGTime class, incidentally, also stored
it's master time stamp in this very same struct. Thus, formatting an
arbitrary time value, would have the unwanted side effect of time travel.
Usually, this would go unnoticed, because the actual time parameters would
be updated before any damage could be done. But unwanted side effects, as
in Brian's example could occur.
On the MSVC port this appears to not have been a problem. Since that port
used a copy of the tm struct to store it's master time stamps. Since the
MSVC code also compiles cleanly on linux, it seems to be the way to go to
use that approach. In addition, it also removes some conditional compile
directives.
I've only run a short test, but didn't see any undesirable side effects.
the MSVC and MipsPro warning stuff).
As a result of this patch, simgear/sg_traits.h can be deleted. So can SGCMath.h,
but I'll do that separately.
There is one more 'mechanical' change to come - getting rid of SG_USING_STD(X),
but I want to keep that separate from everything else. (There's another mechnica
l change, replacing <math.h> with <cmath> and so on *everywhere*, but one step a
t a time)
that interdependencies between sg libs are generally unwelcome, but
sg_exception is a rather basic part, and it's already used by xml, props,
scene, sound and, of course, structure. Since props and xml are core
libs, we can assume that sg_exceptions are available. (OK'ed by Curt)
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
After much trial and tribulation, Harald came up with a fix for the bug
which has been plaguing Cygwin for a couple of weeks now.
It's only a couple of lines. I've tested it exhaustively, and it seems to
cure the problem of Cygwin failing to start.
the dimensions provided.) We draw the sky dome before everything else
and draw it with depth buffer off so it really doesn't matter, but it just
makes a little more sense this way.
Updated a few doxygen comments.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Remove a hack that originally worked around a buffer overflow
elsewhere in the file. The buffer overflow was fixed long ago, but
the hack was not removed.
This module works mostly with char* and allocates memory with
strdup ... delete doesn't go well with malloc(). The transition
to string only would be nice, but some class interfaces return
char*, so it was more natural to just drop the deletes.
at several places material was copied to "buffer" using strncpy
without adding a closing '\0'. This again lead to access to non
initialized memory and potentially (and actually at least in one
case) to feeding garbage to atof(). In case the following garbage
happened to start with digits, we would get funny time
values. :-)
I just added the obligatory "buffer[n] = 0", which doesn't
really look professional now. Maybe we should use the string
class or define a helper function that strncopies =and= adds
a trailing zero?
The last hunk fixes another buglet, that wasn't dangerous
at all, but caused an error message. The loop that should cut
the string at hash marks ('#') did neither stop at such, nor at
string ends. It always scanned the whole 256 character long
buffer and accessed uninitialized memory. valgrind doesn't
like that. I dropped the 256 counter, because fgets =does=
add the closing zero. It is safe to scan until we either
get the zero or the hash mark.
time calculations for an alternate calendar time (i.e. if the application
is being driven from an external source of data.)
Fix a bug in sg_binobj.cxx which disrupted the 'broken down time' globally
for the entire application.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
model math blows up, the lat/lon could be nan. Thus updateLocal() could
potentially called with nan arguments if FlightGear is reiniting from a
blown up state. This is a bug in FlightGear, but I've added a simple
check to catch this so updateLocal() is robust if called under these
circumstances.
James Turner