Could the file(), dir(), base() and extension() functions be made const member
functions. As it stands they cannot be applied to const reference/pointer
values which limits their usefulness.
Curt:
Yes.
- added a new class in simgear/misc, SGTabbedValues, which parses a
null-terminated string of data separated by tabs into fields, and
supports safe conversion into various other datatypes.
I've had to hack Simgear's configure.ac quite a bit [for Mac OS X],
using the Plib one as a reference.
The basic construct (a big switch statement based on the target
type) is nice, I think, since it moves lots of IRIX / cygwin / OS-X
specialties out of the way cleanly. Much more re-factoring of the
current tests in configure is possible if people are able to test.
Attached is the new, improved SkyCloud.cpp. Tested on west coast @ KSFO and
east @ KJFK. Don't have any southern hemisphere or other airports to test
against, but you might give it a go and see what happens
Probably a good idea to add some user options to set cloud altitude, startup
position, etc, but for now this should suffice.
- 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.
2. I changed Simgear's autogen.sh so it is quieter, and errors out if
autoheader or autoconf fails. It puts all error output in autogen.err, and
deletes it if nothing errored out. The patch is in (sg.autogen.sh.patch.gz)
This patch applies to flightgear, too. If someone doesn't like what I did
here, please speak up! I really believe that this patch will help cause
less confusion among people new to compiling flightgear.
Here are some changes that gave me a significant frame rate increase of about 10 fps with random objects disabled. The interesting thing is that these changes aren't in the main loop but are in tile loader. My guess is that I've reduced the memory footprint just enough to reduce CPU cache misses, though I have no hard evidence of this.
Initially I modified all SGBinObject member functions to pass/return by reference instead of by-value. This gives little or no speed up but allows for some optimizations in fgBinObjLoad(). It is these changes that reduce the number of memory allocations. Needless copying of vectors, and vectors of vectors, can be very memory intensive, especially if they are large.
Anyway I would be interested to see if you get similar results. I would emphasize that the frame rate increase only occurs with random objects disabled. I lose about 10-15 fps on my GF2MX 32MB with random objects, probably a fill-rate limitation or texture memory thing.
Here's a first cut at SGSocket reimplemented using plib.net. I've
maintained the same TCP server behaviour, that is only one client
connection at a time. I don't think it is possible within the current
framework to handle simultaneous clients.
I've also added two simple test programs, tcp_client and tcp_server.
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.
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.
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).
-----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
The md5 sums of the source archives are:
abc405d0bdd3ee22782d7aa20e440f08 zlib-1.1.4.tar.gz
ea16358be41384870acbdc372f9db152 zlib-1.1.4.tar.bz2
IV. Acknowledgments
Thanks to Owen Taylor and Mark Cox of Redhat, Inc. for the
reporting and research of this vulnerability.
This document is available from
http://www.gzip.org/zlib/advisory-2002-03-11.txt
The public PGP key of zlib author Jean-loup Gailly is available from
http://www.gzip.org/zlib/jloup.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8jSR02aJ9JQGWcacRAuDEAKCWdrRkWeJV9lYU5z8NN56s3m8eKACglR4m
42KDUGHuftBkwACTMCnZLEo=
=3yLS
-----END PGP SIGNATURE-----
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.
curt