Re: Add vorbis_dsp_init() ?

2009/3/16 Conrad Parker <[email protected]>:
> 2009/3/16 Gregory Maxwell <[email protected]>:
>> On Sun, Mar 15, 2009 at 10:44 AM, [email protected]
>> <[email protected]> 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.

I've included the initialization of vorbis_dsp_state directly into libfishsound,
as suggested by Erik:

https://trac.annodex.net/changeset/3901

Conrad.