On Fri, Mar 20, 2015 at 11:26:34PM +0100, Michael Niedermayer wrote: > On Fri, Mar 20, 2015 at 10:31:56PM +0100, Lukasz Marek wrote: > > On 20.03.2015 14:55, Michael Niedermayer wrote: > > >On Fri, Mar 20, 2015 at 03:01:56AM +0100, Mariusz Szczepańczyk wrote: > > >>From: Lukasz Marek <lukasz.m.lu...@gmail.com> > > >> /** > > >>+ * Open directory for reading. > > >>+ * > > >>+ * @param s directory read context. Pointer to a NULL pointer must > > >>be passed. > > >>+ * @param url directory to be listed. > > >>+ * @param options protocol options. > > >>+ * @return >=0 on success or negative on error. > > >>+ */ > > >>+int avio_open_dir(void **s, const char *url, AVDictionary **options); > > > > > >why void ** ? and not a more specific type ? > > >a more specific type would allow the compiler to check types > > > > I can't remember exactly why, but as far as I remember > > it could be URLContext, but it is not a public struct. > > > Also, creating dummy struct, to have it stored as void * inside is > > not much better, but maybe it is. (the same as AVIOContext stores it > > in void *opaque) > > I think the type should not be void ** when in fact theres only one > type that is valid and allowed > Its different if it would be intended to allow multiple types > > The goal is that a user application cannot mistakely pass the wrong > type > If a struct was used, the layout of that struct does not need to be > defined in a public header so it can be a URLContext
to clarify this as it maybe could be misunderstood a public struct like AVDirectoryWhatever and that contains a URLContext [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
