[FFmpeg-devel] [PATCH] avformat/utils: add helper functions to retrieve index entries from an AVStream

[Nicolas George]

James Almer (12021-04-01):
> Yet the line has to be drawn somewhere. Otherwise public headers would be
> chock full of structs and/or fields normally kept in internal headers
> because "Someone may find them useful".

You are right, the line has to be drawn somewhere. I posit that the best
place to draw the line is defined by laziness: let us make things
private by default; but if something needs to be public, then let us
make it public in the simplest possible way. We need to think ahead
about what would be a maintenance or compatibility hassle, but apart
from that, we should not spend time deciding which bit needs to be
public and which bit needs to be private. We just chose the simplest
solution.

> Please refrain from making such accusations.

I insist: the direct consequence of what you want is to complicate
things, therefore I consider it is fair to write that in this particular
instance "you want to complicate things".

But more importantly, it is not an accusation: I state it only in the
hope that it will be useful, to you and to the project.

Still in the hope to be useful, I will elaborate. I believe I have
observed a bias in your policy towards the project. Knowing that it
might just be imagination plus confirmation bias from me, I still
believe it is useful to let you know about it. It is easier to spot
biases in others than in oneself.

The bias I believe you have is to underestimate mundane complexity: the
cost of typing a few more keys (or to have to rely on advanced features
of an editor); the cost of reading longer lines of code; the cost of
remembering the order of the arguments of a function; the cost of
remembering in which half of a structure that has been split a
particular field has arrived, etc.

All this is tiny, but it is everywhere, and tiny times many, it starts
to accumulate, and it makes working on the project that less fun.

This is not an accusation, I just suggest that you think about it.

> I want to not return a volatile pointer if i can avoid it, because no
> matter how many warnings you add or how much you trust the user, it's
> an unsafe practice. But if both you and Anton consider it the less
> problematic solution, then fine, lets go with it.

I will pile up on this:

In C every function that accepts a pointer as argument or that returns a
pointer comes with caveats about the validity of the pointer.

Just a few common cases: some functions will free their arguments with
generic free(); some functions will free them with a specific handler;
some functions will keep the pointer and expect it to stay valid; some
functions will demand that you free what they return, again, with
generic or specific handlers. The list goes on and on and on.

There are no exception: when you meet a new function with pointers, you
cannot guess the hypotheses it makes about the pointers (unless it is
very similar to a function you already know, and even then you can have
bad surprises), you have to look at the doc. And if you do not, you will
get segfaults or memory leaks or memory corruption.

And every C programmer knows it. Possibly not in as many words, but what
I wrote just now will be no surprise for any C programmer skilled enough
to use the FFmpeg libraries.

The constraint "only valid until the next function call on the same
structure" is not the most common, nor the least dangerous, but it is
not exceptional at all. And in this case, it is by far both the most
simple and the most efficient solution.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210406/0d2a3215/attachment.sig>