[vorbis-dev] Bug fix, win32 stuff

[Monty]

> At 12:09 AM 5/1/00 -0700, you wrote:
> >There was a bug in the new ov_open_callbacks where it would
> >not zero out some member variables of the file info struct,
> >and if a file was not successfully opened this would cause
> >a crash at destruct time.  Fixed.
> 
> This fixes an unrelated bug, I think (Not a bug I've actually seen, though
> - I haven't done any real testing with chained bitstreams) - looks like it
> wasn't allocating enough memory for cases where there's more than a single
> logical bitstream here. This also initialises the memory - obviously, this
> isn't doing any HARM, but I can't see why it would help. As far as I can
> see, the code initialises this  memory to 0 in vorbis_comment_init() and
> vorbis_info_init() in every possible path, so this just initialises it
> twice - not exactly the most efficient method.

...actually, Jon is doing the right thing; even unused members have to be in a
known state at all times so that the 'object' is always safe to destroy.  Just
in case.  zeroing something twice is not a major waste in the interest of
bulletproofing.

A destructor must always be safe; internal inconsistency due to failure halfway
through a process is a bad thing.  If I've made this mistake (allowing 
inconsistent data), than that's a bug and I should be docked a beer :-)

> >In order to get everything compiling cleanly across both win32
> >and linux, I had to add a new file "os_types.h" into the public
> >include directory.  This contains the defintions of types such
> >as int64_t.  It was necessary to put that there because
> >some of the other public include files use these types.
> >
> >I could have moved os.h into the public include directory but
> >it seemed that os.h includes some things that the user really
> >does not need to see, and this will only become more so over
> >time.  So I made the choice of splitting it into 2 files.
> >I am of course open to suggestions if anybody has a better
> >solution.
> 
> I discussed all this with Monty several weeks ago when we were getting the
> original round of win32 fixes in. It was decided that for platforms where
> these types weren't defined correctly, the definitions should be made in
> that platform's project file/makefile/etc. My win32 build here (VC++ 5)
> does this, defining these types within the project file.

As much as is reasonably possible should go into the project... I'm very
allergic to ifdefs. However, there's such a thing as too much blind dogma and
we may end up creating too much work by insisting on no platform specific code
in the mainline headers or lib source.  

What I don't want is #ifdefs laced throughout the code.  I'd also like to 
avoid ifdef trees even in reasonably well contained areas if avoidable.  
Perhaps having an (eg) os_win32.h in the lib source and a (eg) public 
public_win32.h in the include/vorbis dir is the cleanest, most transparent way 
to do this without making things more difficult for developers on either side 
of the APIs.

This is not a final decision, just my thoughts on the subject. Feel free to 
comment.

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/