Minor issues in objc2-audio-toolbox #859

Activity

1. madsmtm

   added

   bugSomething isn't workingSomething isn't working

   enhancementNew feature or requestNew feature or request

   A-frameworkAffects the framework crates and the translator for themAffects the framework crates and the translator for them

   on Sep 5, 2026
2. madsmtm commented on Sep 5, 2026

   

   madsmtm

   on Sep 5, 2026

   Last edited by madsmtm

   Owner

   More actions

   Thanks for the feedback! I haven't spent that much time using objc2-audio-toolbox (and the other audio-related crates), so it's very useful.

   Interacting with types with flexible array members

   I've actually recently looked into this a bit in 6cb2534 from a soundness perspective: It's now enforced that you cannot construct these types safely, and the unsound derives are also gone.

   E.g. AudioBufferList has changed like this (and can only ever be gotten behind pointer types like NonNull or *mut):

     #[repr(C)]
   - #[derive(Clone, Copy, Debug, PartialEq)]
     pub struct AudioBufferList {
         pub mNumberBuffers: u32,
         pub mBuffers: [AudioBuffer; 1],
   +    _this_is_unsized: (),
     }

   That does nothing to resolve your point about them still having terrible usability though.

   I think it would be better if the array member had a size of zero and not one, so it can be treated as a header part only.

   The annoying thing here is that AudioBufferList.mBuffers isn't actually a flexible array member! The definition in the header is roughly:

   /*!
       @struct         AudioBufferList
       @abstract       A variable length array of AudioBuffer structures.
       @var            mNumberBuffers
                           The number of AudioBuffers in the mBuffers array.
       @var            mBuffers
                           A variable length array of AudioBuffers.
   */
   struct AudioBufferList {
       UInt32 mNumberBuffers;
       AudioBuffer mBuffers[1]; // this is a variable length array of mNumberBuffers elements
   }

   Which means the header translator has to guess that mBuffers is a FMA because it only has 1 element (and without more information, the conservative option is to keep emitting this as a 1-sized array too).

   Or better yet, if there were helper methods for allocating/accessing/deallocating structs with FAMs.

   Good idea, we could probably add that. Do you have ideas for a design here? Ideally some generic design that we can auto-generate for all structs with FAMs, and ideally one that can re-use an existing &mut [u8] allocated somewhere else (so that you can choose to do static allocation instead).

   Callback types (AURenderCallback and friends) are Option<fn(...) -> ...>, which is slightly annoying if you want to store the inner function pointer without the Option (you have to refer to it by its full name). Not a big deal.

   Good point, we could probably push the optionality out of the typedef. I'll look into this.
   EDIT: Done in 79ded6b.
3. madsmtm

   added a commit that references this issue on Sep 5, 2026

   Push function pointers' nullability out of typedefs

   ...

   79ded6b
4. madsmtm

   removed

   bugSomething isn't workingSomething isn't working

   on Sep 16, 2026