On 7/10/2020 11:29 AM, Nicolas George wrote: > James Almer (12020-07-10): >> It's adding an extra parameter to get a value that ultimately can be >> derived from the output of another parameter. If you can use the >0 part >> of the return value for that, > > Yes. And for me, it is totally a good thing.
Then we have different opinions. > > So why are you calling it ugly? Because my opinion and tastes are not yours. I already said why *i* consider it ugly. It doesn't need to fit *your* conception of ugliness. > > This discussion feels to me like "Why is planting trees a bad thing? - > It makes the neighborhood greener." > > Ugly is using the same channel to carry to completely different pieces > of information. And extra parameters are not a bad thing. They are a good thing when they provide useful information that can't be derived from other information, or at least not easily. So returning pointers, plane sizes and line sizes in separate parameters, like av_image_fill_pointers() does, is great. But the suggestion i made earlier as an alternative to this is superfluous duplication. So lets do int av_image_fill_plane_sizes(size_t sizes[4], enum AVPixelFormat pix_fmt, const ptrdiff_t linesizes[4]); Making it consistent with av_image_fill_linesizes() (ideal approach considering the point of the function is also to fill an array of sizes) while also introducing size_t and ptrdiff_t to start the eventual type migration for the rest of the module. > > Regards, > > > _______________________________________________ > 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". > _______________________________________________ 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".
