[FFmpeg-devel] [PATCH] avformat/hlsenc: Fix path handling on Windows

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Andreas
> Rheinhardt
> Sent: Saturday, January 15, 2022 7:40 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Fix path handling on
> Windows
> 
> ffmpegagent:
> > From: softworkz <softworkz at hotmail.com>
> >
> > Signed-off-by: softworkz <softworkz at hotmail.com>
> > ---
> >     avformat/hlsenc: Fix path handling on Windows
> >
> >     Handling for DOS path separators was missing
> >
> > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-19%2Fsoftworkz%2Fsubmit_hlspath-v1
> > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> 19/softworkz/submit_hlspath-v1
> > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/19
> >
> >  libavformat/hlsenc.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index ef8973cea1..eff7f4212e 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -3028,6 +3028,10 @@ static int hls_init(AVFormatContext *s)
> >                  }
> >
> >                  p = strrchr(vs->m3u8_name, '/');
> > +#if HAVE_DOS_PATHS
> > +                p = FFMAX(p, strrchr(vs->m3u8_name, '\\'));
> > +#endif
> > +
> >                  if (p) {
> >                      char tmp = *(++p);
> >                      *p = '\0';
> >
> > base-commit: c936c319bd54f097cc1d75b1ee1c407d53215d71
> >
> 

Thanks for reviewing.

> 1. You seem to be under the impression that NULL <= all other pointers.
> This is wrong. Relational operators acting on pointers are only defined
> when both point to the same object (the case of "one past the last
> element of an array" is also allowed) and are undefined behaviour otherwise.

The case about NULL is interesting - I wasn't aware of that.
Is it practically relevant, i.e. is there any platform where casting 
(void *)0 does not evaluate to 0 ?

> 2. Apart from that: Your code would potentially evaluate strrchr()
> multiple times which is bad style (given that this function is likely
> marked as pure the compiler could probably optimize the second call
> away, but this is not a given).

It's not my code. It's code copied from avstring.c - so please blame
whoever that wrote.

Regarding performance, I'm not sure whether this is relevant in any way,
given the low frequency of execution and putting it into relation to 
all the other things that ffmpeg is doing usually.

> 3. The code in av_basename() is also wrong.

...

> 4. Is there actually a reason why you don't use av_basename() directly here?

Yes, multiple:

1. Different behavior - those functions are returning a "." when not found
2. The docs tell it's required to copy a string before supplying it to
   those functions (as they may changing the string).
3. The hlsenc code changes the string temporarily and restores it after
   wards. The same couldn't be done when using the avstring functions.

Thanks,
softworkz