[FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Martin
> Storsjö
> Sent: Monday, May 23, 2022 1:12 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel at 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-bounces at ffmpeg.org> On Behalf Of
> Martin
> >> Storsjö
> >> Sent: Monday, May 23, 2022 12:58 PM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> devel at 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-bounces at ffmpeg.org> On Behalf Of
> >> Martin
> >>>> Storsjö
> >>>> Sent: Monday, May 23, 2022 12:53 PM
> >>>> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel at 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