[Vorbis-dev] Add vorbis_dsp_init() ?

[Conrad Parker]

2009/3/16 Gregory Maxwell <gmaxwell at gmail.com>:
> On Sun, Mar 15, 2009 at 10:44 AM, ogg.k.ogg.k at googlemail.com
> <ogg.k.ogg.k at googlemail.com> wrote:
>>> Is a memset of zeros also promised to create proper null pointers just
>>> as assigning with zero?  (The value in memory for a null pointer isn't
>>> guarenteed to be the all zero bit sequence)
>>
>> Pedantically, I think not (though I'm very hazy with the distinction
>> of the null pointer and its bit pattern that can be non zeros).
>> Are you aware of an implementation that does this ? I do recall
>> eerie discussions about assigments of a pointer with 0 yielding
>> this non zero bit pattern, but that was years ago.
>>
>> Moreover, I'm entirely in the dark what would then happen to:
>>
>> void foo(char *p)
>> {
>>  if (p) *p=0;
>> }
>>
>> Would the test of p test against the null pointer, or cast p to an
>> int, then test this int ?
>
>
> There is zero ambiguity: If(pointer) is testing nullness. *pointer=0
> makes the pointer null (even if the null pointer is not zero). These
> are special cases explicitly addressed in the standard. :)
>
> There are real platforms today (oddball small embedded things) where
> the null pointer is not 0.  I doubt anyone is using Vorbis on any of
> these and I wouldn't be surprised if libvorbis doesn't work on them,
> but gratuitous incompatibilities should be avoided.
>
> I asked because I wasn't sure if memsetting with zeros was some
> additional exception case, but I'm pretty sure it's not, and I was
> simply curious.
>
> Since I've already spoken up, I might as well have my say on the color
> of the shed...
>
> The issue here is that you never call headerin on a file without
> headers, then you later lose your mind since the headerin would have
> initilized some things. Right?  Why not make it so headerin can be
> called with a null packet, and make it the API rule that you always
> call headerin?  (I ask more to satisfy my own limited understanding of
> the vorbisfile API then to suggest that the change is wrong…)

firstly, it's the libvorbis API, not the libvorbisfile API -- the
difference being that when you use libvorbis directly, you need to
handle the Ogg encapsulation separately. You need to do this to decode
the audio track of video streams. If there is an error at the Ogg
layer you need to be able to take that into account, which is what's
happening here.

Code does always call vorbis_synthesis_headerin(); without that it
can't initialize the vorbis_info struct. The way that function works
is a little strange: you call it multiple times with the same
arguments (pointers to vorbis_info and vorbis_comment structs). The
vorbis_info is filled in by the first and third invocations, and the
vorbis_comment by the second.

So, the issue here is that although headerin is called, one of the
initializations of the vorbis_info is not done. It's simpler to just
initialize the structures from the calling application (here,
libfishsound) than to add code to track which headers are being
handled and then make assumptions about how much initialization has
been done by libvorbis.

Conrad.