Re: [FFmpeg-devel] [PATCH 2/8] lavu: new AVWriter API - Rémi Denis-Courmont

From: "Rémi Denis-Courmont" <remi@remlab.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/8] lavu: new AVWriter API
Date: Tue, 02 May 2023 21:29:24 +0300
Message-ID: <2651731.DzIsRRP5fV@basile.remlab.net> (raw)
In-Reply-To: <ZFFAF1ZhJqNA78wc@phare.normalesup.org>

Le tiistaina 2. toukokuuta 2023, 19.53.43 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-05-02):
> > Indirecting the printf function seems pretty pointless. The last thing you
> 
> Please re-read the code, there is no other way of obtaining a va_list
> from an actual argument than making a call to a vararg function.

Please re-read the comments. You are totally misses the point.

> > As for hypothetical use cases whence vasprintf() wouldb e "too slow", then
> > should not use printf()-style or function pointers to begin with. Besides
> > if you _really_ want to avoid the heap allocation, you can also use
> > fopencookie() on systems that provide it or equivalent.
> 
> Being portable and not doing dynamic allocation are two major points of
> the design, so you will excuse me if I pass on that suggestion.

Well, I'll add myself to the already long list of people publicly objecting to 
your patchset then.

> There is nothing about heap allocation in this code. And if code can be
> in the framework common to all backends, then it is where it belongs,
> not duplicated in each backend.

This makes zero sense. Why the hell would you want to have more than one heap-
allocation backend.

> > This is an abstraction inversion (and also highly inefficient) + what I
> > noted above.
> 
> See above, it is necessary. (If you think it is not, try doing better.)

Well duh, I wrote the VLC equivalent years ago. And glibc or FreeBSD libc did 
them more than a decade before I did.

> > This is an analogue of puts/fputs, not "print".
> 
> This is an analogue of puts, fputs and print, and I decided to call it
> print.

And I decided to object to that on the basis that it's dumb and confusing.

> I think you are missing something important about the purpose of this
> code, but I cannot guess what exactly. Please be more detailed about why
> you think it is overengineered and point how you would do it simpler.

I think I was pretty damn clear and you are just deliberately making up reason 
to ignore other people's comments (not just mine).

-1

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/

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

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