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-requ...@ffmpeg.org with subject "unsubscribe".
