On Mon, Mar 29, 2021 at 12:19:57PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-03-15 09:47:43)
> > Suggested-by: Andreas Rheinhardt
> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > ---
> >  libavutil/common.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavutil/common.h b/libavutil/common.h
> > index aee353d399..c2d47a45b4 100644
> > --- a/libavutil/common.h
> > +++ b/libavutil/common.h
> > @@ -108,6 +108,8 @@
> >  #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
> >  #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
> >  
> > +#define FF_PTR_ADD(ptr, off) ((off) ? (ptr) + (off) : (ptr))
> 
> IIUC Andreas suggested to either put an AV prefix on this or move it to
> an internal header. I agree with that and prefer the latter, this macro
> doesn't seem very useful for external callers.

ill move it to internal.h

I think though our headers are not optimally named and the terminology used is
a bit ambigous. for example what exactly is external ? outside the lib, all 
libs maintained
by us, outside the soname object, ...

whats the header that is internal to libavutil ?
libavutil/internal.h, nope

whats the header with API common to all our libs in libavutil ?
libavutil/common.h, nope though it contains a good part of that API

I know these still it feels wrong every time i see a
#include "libavutil/internal.h" outside libavutil

Probably its just me but even after years this naming system still feels odd to 
me

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to