diff mbox series

[FFmpeg-devel,1/2] avutil/common: Add FF_PTR_ADD()

Message ID 20210315084744.7341-1-michael@niedermayer.cc
State New
Headers show
Series [FFmpeg-devel,1/2] avutil/common: Add FF_PTR_ADD()
Related show

Checks

Context Check Description
andriy/x86_make success Make finished
andriy/x86_make_fate success Make fate finished
andriy/PPC64_make success Make finished
andriy/PPC64_make_fate success Make fate finished

Commit Message

Michael Niedermayer March 15, 2021, 8:47 a.m. UTC
Suggested-by: Andreas Rheinhardt
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavutil/common.h | 2 ++
 1 file changed, 2 insertions(+)

Comments

Anton Khirnov March 29, 2021, 10:19 a.m. UTC | #1
Quoting Michael Niedermayer (2021-03-15 09:47:43)
> Suggested-by: Andreas Rheinhardt
> Signed-off-by: Michael Niedermayer <michael@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.
Michael Niedermayer March 30, 2021, 10:44 p.m. UTC | #2
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 <michael@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

[...]
Anton Khirnov April 1, 2021, 8:02 a.m. UTC | #3
Quoting Michael Niedermayer (2021-03-31 00:44:16)
> 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 <michael@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

I certainly agree that it's messy and efforts to improve it are very
much welcome.

In this case at least, by external I mean the stable API we provide to
other projects. And I think there's broad consensus that
- all global external identifiers provided by us in installed headers
  should be AV/av-prefixed
- installed headers should, as much as possible, not declare anything
  that is not public API

Neither of those are completely true today, but it's a goal we should be
trying to approach.
diff mbox series

Patch

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))
+
 /* misc math functions */
 
 #ifdef HAVE_AV_CONFIG_H