curt [Fri, 10 May 2002 13:32:44 +0000 (13:32 +0000)]
Bernie Bright:
Here is a total rewrite of the strutils package. I've reimplemented the
trimleft(), trimright() and trim() functions as lstrip(), rstrip() and
strip() respectively. Additionally I've added a split() function that
behaves like its perl/python equivalent. Just the thing for splitting
comma separated option strings or space separated telnet commands and
arguments. I've also enclosed the whole thing in a namespace
simgear::strutils. Since I seem to be the only one who uses these
functions, SimGear and FlightGear compile without change.
PS It is no coincidence that the new function names bear an uncanny
resemblance to the python functions of the same name.
david [Thu, 25 Apr 2002 15:09:10 +0000 (15:09 +0000)]
Patches from Erik Hoffman:
Tbis is a first patch in a series to clean up SimGear by removing
warning messages. Most of them are straight forwared, but in pops.hxx
the compile complaints about "type qualifier is meaningless on return
type". I think it's up to you to decide if you want that part applied.
david [Sun, 7 Apr 2002 21:28:43 +0000 (21:28 +0000)]
Patch from Frederic Bouvier:
A const char * is not supposed to change and cannot be deleted. So
here is a patch that remove unnecessary const from props.hxx and
props.cxx. There also is the addition of a friend directive because
nested classes do not receive special privileges and cannot access
private members of the outer class.
Added src-libs subdirectory for keeping source code to extra libs. These
are things that are needed, but that many systems already have packages
available to install, and many users may have versions of these already
installed to support other projects. So rather than build and install by
default with the main SimGear build/install, these are kept separate so that
those users that don't have them already installed can build and install
them separately.
- Added src-libs/boost.tar.gz and README.boost. This is in anticipation
of actually using them in the flightgear event manager.
- Now that we have several add on libs we are bundling with simgear (but
not automatically built as part of the simgear build) I have moved them
to their own subdirectory (src-libs).
curt [Thu, 28 Mar 2002 02:21:00 +0000 (02:21 +0000)]
Updated to the latest metakit release. This fixes a few bugs that could
possibly affect some users. For details, see the metakit changelog at
the metakit home page: ttp://www.equi4.com/metakit/
david [Wed, 27 Mar 2002 11:42:09 +0000 (11:42 +0000)]
Patch from Melchior Franz:
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.
david [Mon, 25 Mar 2002 19:56:48 +0000 (19:56 +0000)]
Patch from Melchior Franz:
Here is a patch that fixes a little problem in dome.cxx: The fog_color
is created in a sgVec3 (227) but then handed over to ::repaint(), which
expects a sgVec4 (282). Then (343) center_color (although defined as
sgVec4) is only initialized with 3 values, but later (441) assigned to
'slot' via sgCopyVec4.
david [Mon, 25 Mar 2002 19:50:32 +0000 (19:50 +0000)]
Patch from Melchior Franz:
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.
david [Tue, 19 Mar 2002 16:07:47 +0000 (16:07 +0000)]
Major property-manager rewrite, using const char * throughout
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
david [Mon, 18 Mar 2002 03:21:18 +0000 (03:21 +0000)]
Code cleanup and minor speed improvements. For the record, accessing
an internally-managed property is nearly twice as fast as accessing
one tied to methods.
curt [Mon, 11 Mar 2002 23:03:19 +0000 (23:03 +0000)]
zlib-1.1.3 had a potential security flaw which is fixed by zlib-1.1.4:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zlib Advisory 2002-03-11
zlib Compression Library Corrupts malloc Data Structures via Double Free
Original release date: March 11, 2002
Last revised: March 11, 2002
Source: This advisory is based on a CERT advisory written
by Jeffrey P. Lanza http://www.kb.cert.org/vuls/id/368819
Systems Affected
* Any software that is linked against zlib 1.1.3 or earlier
* Any data compression library derived from zlib 1.1.3 or earlier
Overview
There is a vulnerability in the zlib shared library that may introduce
vulnerabilities into any program that includes zlib. This
vulnerability has been assigned a CVE name of CAN-2002-0059
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0059
I. Description
There is a vulnerability in the decompression algorithm used by the
popular zlib compression library. If an attacker is able to pass a
specially-crafted block of invalid compressed data to a program that
includes zlib, the program's attempt to decompress the crafted data
can cause the zlib routines to corrupt the internal data structures
maintained by malloc.
The vulnerability results from a programming error that causes
segments of dynamically allocated memory to be released more than once
(aka. "double-freed"). Specifically, when inftrees.c:huft_build()
encounters the crafted data, it returns an unexpected Z_MEM_ERROR to
inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to
infblock.c:inflate_blocks(), the inflate_blocks function tries to free
an internal data structure a second time.
Because this vulnerability interferes with the proper allocation and
de-allocation of dynamic memory, it may be possible for an attacker to
influence the operation of programs that include zlib. In most
circumstances, this influence will be limited to denial of service or
information leakage, but it is theoretically possible for an attacker
to insert arbitrary code into a running program. This code would be
executed with the permissions of the vulnerable program.
II. Impact
This vulnerability may introduce vulnerabilities into any program that
includes the affected library. Depending upon how and where the zlib
routines are called from the given program, the resulting
vulnerability may have one or more of the following impacts: denial of
service, information leakage, or execution of arbitrary code.
III. Solution
Upgrade your version of zlib
The maintainers of zlib have released version 1.1.4 to address this
vulnerability. Any software that is linked against or derived from an
earlier version of zlib should be upgraded immediately. The latest
version of zlib is available at http://www.zlib.org
curt [Sun, 10 Mar 2002 22:49:01 +0000 (22:49 +0000)]
Additions to the binary file format to make it *much* more flexible.
For each major primative type: points, triangles, fans, and strips, you
can specify an index list of vertices, normals, colors, and texture
coordinates. You can skip any of these you like to save on space.
Note that the work for this has only been done in the file format reader
and writer. The FlightGear loader for instance still needs to have
support for this built in.
This is is one more small step towards runway lighting.
david [Sun, 3 Mar 2002 21:22:24 +0000 (21:22 +0000)]
Modified to add an optional parameter to writeProperties to allow
*all* properties to be written, rather than just the ones flagged as
archivable. Tony Peden requested this feature to make it easier for
people to document properties.
david [Tue, 19 Feb 2002 15:20:02 +0000 (15:20 +0000)]
IMPORTANT: backwards-incompatible change to properties.
The useDefault argument for the SGPropertyNode::tie(...) methods will
invoke the setter only when there is already a property value defined;
previously, the setter was always invoked, with a default value if
necessary.
curt [Mon, 11 Feb 2002 22:27:27 +0000 (22:27 +0000)]
Decouple sg_time code from the current time(NULL), i.e. you can run the
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.
curt [Mon, 4 Feb 2002 20:23:41 +0000 (20:23 +0000)]
Pass strings by const reference instead of by value,
Made fix_path() a private member function, SGPath::fix(),
Added bool SGPath::exists(),
Added an assignment operator that acts like SGPath::append().
curt [Sat, 29 Dec 2001 00:38:04 +0000 (00:38 +0000)]
Removed metakit and zlib from the configure/build process. The
developer will need to build and install these separately if they
don't have packages already installed by their system. See
README.metakit and README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source
code trees are included with the simgear distribution (and cvs.)
curt [Sat, 29 Dec 2001 00:35:34 +0000 (00:35 +0000)]
Removed metakit and zlib from the configure/build process. The
developer will need to build and install these separately if they don't
have packages already installed by their system. See README.metakit and
README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source code
trees are included with the simgear distribution (and cvs.)
curt [Fri, 28 Dec 2001 21:27:19 +0000 (21:27 +0000)]
Updates to build system to better support automake-1.5
- 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.
david [Wed, 12 Dec 2001 02:28:28 +0000 (02:28 +0000)]
Added trace attributes to properties:
TRACE_READ - log a message whenever the property is read.
TRACE_WRITE - log a message whenever the property is written.
The second one works only when the property value is changed through
the property manager; tied variables and accessors are not polled for
value changes because of the performance hit.
These methods end up invoking private methods
SGPropertyNode::trace_read and SGPropertyNode::trace_write. By
setting breakpoints on these methods inside a debugger, it is possible
to debug property access and find what parts of a program are reading
or writing specific property values by doing a backtrace.
In the XML property files, users can use the attributes 'trace-read'
and 'trace-write' to control tracing; the value should be 'y' to
enable tracing or 'n' to disable it (the default).
curt [Wed, 5 Dec 2001 22:31:03 +0000 (22:31 +0000)]
In certain degenerate situations on the FlightGear side when the flight
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.
curt [Tue, 27 Nov 2001 03:17:43 +0000 (03:17 +0000)]
Christian M. says it's bad to chain one constructor call from another.
I can't find anything that addresses this in Stroustrup, but I also don't
see them doing this in any of their examples. So I have rewritten this
instance to use default arguments to accomplish the same thing. I imagine
there are other instances of this same sort of thing in other classes to
be fixed at a later date.