Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Marton Balint <cus@passwd.hu>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 01/21] avformat/avio: Don't use incompatible function pointer type for call
Date: Fri, 8 Sep 2023 22:38:50 +0200 (CEST)
Message-ID: <7cf28856-6611-ab55-256-f834ea24bc5@passwd.hu> (raw)
In-Reply-To: <AS8P250MB07440B2119F95B5951BA54298FEEA@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM>



On Thu, 7 Sep 2023, Andreas Rheinhardt wrote:

> It is undefined behaviour even in cases where it works
> (it works because it is only a const uint8_t* vs. uint8_t* difference).
>
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
> ---
> libavformat/avio.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index ab1c19a58d..d53da5cb0c 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -354,10 +354,15 @@ fail:
> }
>
> static inline int retry_transfer_wrapper(URLContext *h, uint8_t *buf,
> +                                         const uint8_t *cbuf,
>                                          int size, int size_min,
> -                                         int (*transfer_func)(URLContext *h,
> -                                                              uint8_t *buf,
> -                                                              int size))
> +                                         int (*read_func)(URLContext *h,
> +                                                          uint8_t *buf,
> +                                                          int size),
> +                                         int (*write_func)(URLContext *h,
> +                                                           const uint8_t *buf,
> +                                                           int size),
> +                                         int read)

These extra parameters are very ugly, can't we think of another way to 
properly support this?

One idea is putting retry_transfer_wrapper in a template file and include 
it twice with proper defines-s for the read and write flavours.

Regards,
Marton


> {
>     int ret, len;
>     int fast_retries = 5;
> @@ -367,7 +372,8 @@ static inline int retry_transfer_wrapper(URLContext *h, uint8_t *buf,
>     while (len < size_min) {
>         if (ff_check_interrupt(&h->interrupt_callback))
>             return AVERROR_EXIT;
> -        ret = transfer_func(h, buf + len, size - len);
> +        ret = read ? read_func (h,  buf + len, size - len)
> +                   : write_func(h, cbuf + len, size - len);
>         if (ret == AVERROR(EINTR))
>             continue;
>         if (h->flags & AVIO_FLAG_NONBLOCK)
> @@ -402,14 +408,16 @@ int ffurl_read(URLContext *h, unsigned char *buf, int size)
> {
>     if (!(h->flags & AVIO_FLAG_READ))
>         return AVERROR(EIO);
> -    return retry_transfer_wrapper(h, buf, size, 1, h->prot->url_read);
> +    return retry_transfer_wrapper(h, buf, NULL, size, 1,
> +                                  h->prot->url_read, NULL, 1);
> }
>
> int ffurl_read_complete(URLContext *h, unsigned char *buf, int size)
> {
>     if (!(h->flags & AVIO_FLAG_READ))
>         return AVERROR(EIO);
> -    return retry_transfer_wrapper(h, buf, size, size, h->prot->url_read);
> +    return retry_transfer_wrapper(h, buf, NULL, size, size,
> +                                  h->prot->url_read, NULL, 1);
> }
>
> int ffurl_write(URLContext *h, const unsigned char *buf, int size)
> @@ -420,9 +428,8 @@ int ffurl_write(URLContext *h, const unsigned char *buf, int size)
>     if (h->max_packet_size && size > h->max_packet_size)
>         return AVERROR(EIO);
>
> -    return retry_transfer_wrapper(h, (unsigned char *)buf, size, size,
> -                                  (int (*)(struct URLContext *, uint8_t *, int))
> -                                  h->prot->url_write);
> +    return retry_transfer_wrapper(h, NULL, buf, size, size,
> +                                  NULL, h->prot->url_write, 0);
> }
>
> int64_t ffurl_seek(URLContext *h, int64_t pos, int whence)
> -- 
> 2.34.1
>
> _______________________________________________
> 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".
>
_______________________________________________
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".

  parent reply	other threads:[~2023-09-08 20:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07  0:23 Andreas Rheinhardt
2023-09-07  0:32 ` [FFmpeg-devel] [PATCH 02/21] avformat/internal: Avoid casting const away Andreas Rheinhardt
2023-09-09  6:38   ` Tomas Härdin
2023-09-07  0:32 ` [FFmpeg-devel] [PATCH 03/21] avformat/aviobuf: Don't use incompatible function pointer type for call Andreas Rheinhardt
2023-09-09  6:46   ` Tomas Härdin
2023-09-09  9:25     ` Andreas Rheinhardt
2023-09-08 20:38 ` Marton Balint [this message]
2023-09-09  6:37   ` [FFmpeg-devel] [PATCH 01/21] avformat/avio: " Tomas Härdin
2023-09-10  8:47     ` Marton Balint
2023-09-10  9:02       ` Andreas Rheinhardt
2023-09-10 18:07         ` Marton Balint
2023-09-10 18:23           ` Andreas Rheinhardt
2023-09-11 17:27           ` [FFmpeg-devel] [PATCH v3] " Andreas Rheinhardt
2023-09-11 18:43             ` Marton Balint
2023-09-12 14:59             ` Andreas Rheinhardt
2023-09-10 10:07   ` [FFmpeg-devel] [PATCH v2] " Andreas Rheinhardt
2023-09-11 16:53     ` Tomas Härdin
2023-09-09  6:36 ` [FFmpeg-devel] [PATCH 01/21] " Tomas Härdin
2023-09-10 10:18   ` Andreas Rheinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7cf28856-6611-ab55-256-f834ea24bc5@passwd.hu \
    --to=cus@passwd.hu \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git