> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Martin > Storsjö > Sent: Monday, May 23, 2022 1:12 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Mon, 23 May 2022, Soft Works wrote: > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Martin > >> Storsjö > >> Sent: Monday, May 23, 2022 12:58 PM > >> To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using > av_fopen_utf8 > >> > >> On Mon, 23 May 2022, Soft Works wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > >> Martin > >>>> Storsjö > >>>> Sent: Monday, May 23, 2022 12:53 PM > >>>> To: FFmpeg development discussions and patches <ffmpeg- > >> de...@ffmpeg.org> > >>>> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using > >> av_fopen_utf8 > >>>> > >>>> On Sat, 21 May 2022, Soft Works wrote: > >>>> > >>>>> LGTM. (all three) > >>>>> > >>>>> Tested with VS project build (full static linkage, though). > >>>> > >>>> I discussed this with Anton on irc, and he was ok with the patchset > >> too, > >>>> so I pushed it now. > >>>> > >>>> // Martin > >>> > >>> Great, thanks. > >>> > >>> Shall I update mine now to cover the remaining fopen() calls? > >> > >> Yep, that sounds good to me. It should be easier to move forward with > the > >> uncontroversial parts of the patchsets now. > >> > >> // Martin > > > > Sure, will do. > > > > I think I have addressed all concerns from the side of nil-admirari; > > the last point was the mapping of the stat() function, which - > > even though it works - could use a few more eyes taking a look at. > > > > Any other specific concerns from your side? > > I haven't followed your discussion closely (I was waiting for it to > converge, which it apparently mostly has) so I haven't got anything to add > offhand right now. I can try to read through the latest iteration (or the > next one if rebased and reposted) and give a more qualified opinion in a > day or two.
Great. I rebased and resubmitted both patchsets. The primary long-path patchset didn't need any change. Considerations for the latter were: - Should the file wchar_filename.h be renamed as it is now containing the path prefixing code? - I have kept the path functions in the same way like .NET does it, just for easy reference and following. Compilers will inline them anyway (my pov). Maybe others don't like that. I can change if it's got to be. - The one ugliness is the copied struct for the mapping of the stat function. Maybe there's some tricky way to get around doing so, I just couldn't find any. I'm very confident about the core functionality, though (due to it origin). Thanks again, sw _______________________________________________ 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".
