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
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".
