From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 8087C423FB for ; Thu, 14 Apr 2022 21:53:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E6CB568B4AA; Fri, 15 Apr 2022 00:53:11 +0300 (EEST) Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id ADD3568B409 for ; Fri, 15 Apr 2022 00:53:05 +0300 (EEST) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-2ec42eae76bso68700017b3.10 for ; Thu, 14 Apr 2022 14:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9qnV/fLRZB0lA08ayUeAym2BPsVl055dLFl6nGpNt+4=; b=hEVLM2LAQRmz5HKjvrxNQaVmk7/we3/ojg6hDVKZQTHmrcj+whJ+mhISfoAo4ZMUlN 72un2yOI2t4XZhpmet4y62fkBW3CKyaJ5iI8g7Lnko3iByU5iW6ofh4Pyz/D/NpFExko yMq7ITPDDh8YDjljm5QtcFnBUP78tdLibTJ3XHuVlNU7vL2TTTNxmX8ofkJ8c3j5TFYZ yClt8yFPVy6i/4M/8jHHLql6qzD8G08HWIR1T86g/04nzAibbTiSc8VvlOSGGrHTdgW+ ClFI8xM9csLoHlcouWL6HYmwooqaI7Q47vaNGXvMzq7ZR2y/Tnkt7PmR5jgxwIlqKSlW ZmKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9qnV/fLRZB0lA08ayUeAym2BPsVl055dLFl6nGpNt+4=; b=07jAig5hA3csFkOR3KK58NAAYHu1BfLrh7BSkoc/YqOzOBE9PdGIGlOc3ZGdgoO1QU 2hN26/Rlg8z4JkD0DMm66TFXfFw6ij5aY/LKquvFl8x9EuI4KjoSwEX0ssdwAd/upx6y 3JbNN7zqnRx8iW4kR8nxAO/Kl0/A+ivypJrmHC61DnzbMGEx18hASSNCXiNa601jZ2T6 8LxZxZ60iVWLMgG7O5KQ5OD9s1eH+BxyMWGJBdCT4Vtg6xLRmB207Dn3OGmtmTED4fNn G096Bh2hnLHMUssGZlxgItQzvDlLoOQ1rqpSRF1nf28BOssLjeNY1PVhZ2Ut/UrNCtG2 mgiw== X-Gm-Message-State: AOAM530BFphgnUgs99Ks8R6r56FaGwmRugRjKBX/MaQ12msLYd1hNjeB 2S7cFjhtUOswNHaWBeJP/4JCKRBWralGLCBbxXDkTiwi X-Google-Smtp-Source: ABdhPJyPeugpsdqXqErDKDIF2S4BH2u07xH/Jz9wwLFYM3kEGMweV1LX/ASq2ijva256JJIdParDBHoYwnyL3xiTGw8= X-Received: by 2002:a81:6188:0:b0:2eb:4bd3:9b86 with SMTP id v130-20020a816188000000b002eb4bd39b86mr3535174ywb.46.1649973183889; Thu, 14 Apr 2022 14:53:03 -0700 (PDT) MIME-Version: 1.0 References: <164872705467.19727.14353472036844305245@lain.red.khirnov.net> In-Reply-To: From: Hendrik Leppkes Date: Thu, 14 Apr 2022 23:52:50 +0200 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 6/7] avcodec: Make avcodec_decoder_subtitles2 accept a const AVPacket* X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Thu, Apr 14, 2022 at 9:33 PM Andreas Rheinhardt wrote: > > Anton Khirnov: > > Quoting Andreas Rheinhardt (2022-03-31 00:49:57) > >> From: Andreas Rheinhardt > >> > >> Signed-off-by: Andreas Rheinhardt > >> --- > >> doc/APIchanges | 3 +++ > >> fftools/ffmpeg.c | 4 ++-- > >> fftools/ffprobe.c | 2 +- > >> libavcodec/avcodec.h | 3 +-- > >> libavcodec/decode.c | 9 ++++----- > >> libavcodec/version.h | 2 +- > >> tools/target_dec_fuzzer.c | 4 ++-- > >> 7 files changed, 14 insertions(+), 13 deletions(-) > >> > >> diff --git a/doc/APIchanges b/doc/APIchanges > >> index 1a9f0a303e..326a3c721c 100644 > >> --- a/doc/APIchanges > >> +++ b/doc/APIchanges > >> @@ -14,6 +14,9 @@ libavutil: 2021-04-27 > >> > >> API changes, most recent first: > >> > >> +2022-03-30 - xxxxxxxxxx - lavc 59.26.100 - avcodec.h > >> + avcodec_decode_subtitle2() now accepts const AVPacket*. > > > > I vaguely recall C++ having a problem with such changes. Anybody > > remembers the details? Do we care? > > > > You did something like this in 0a0f19b577d54ff2e72cc9a0fe027952db83f332 > without a major bump; IIRC there are more instances likes this. > > For C functions, the signature is not part of the exported symbol name > (as zhilizhao already said) and the ABIs just presume that the caller > and callee agree on the signature. Constifying this parameter does not > break this, as "pointers to qualified or unqualified versions of > compatible types shall have the same representation and alignment > requirements" (C11 6.2.5/26). > > Ordinary API usage will be fine, because the conversion from AVPacket* > to const AVPacket* is safe and therefore performed automatically; it > requires no cast. API-wise there is only one thing that might cause > problems: If one does not use avcodec_decode_subtitle2 directly, but > via a function pointer like this: > > #include > > typedef int (*unconst)(AVCodecContext *, AVSubtitle *, int *, AVPacket *); > > void foo(void) > { > unconst funcptr = avcodec_decode_subtitle2; > > /* use funcptr */ > } > > Here the initialization of avcodec_decode_subtitle2 is not fine; for C > compilers will by default emit a warning, for C++ it is common to fail. > But avcodec_decode_subtitle2 is the only function with this signature > at all, so it makes no sense to use function pointers instead of using > this function directly. I don't think that anyone does and therefore my > answer to your last question is: I don't really care given that ordinary > usages are fine. > If one does manual dynamic loading (eg. for optional components), you would use a function pointer .. for all functions, not just this one. On the other hand, if you use C++ and you manually define the type for every function pointer (as we don't define function pointer types), its a rather fragile construct to begin with, especially as you could just infer the types automatically using decltype constructs, in which case there would be no issues as it just updates automatically. In theory such a change can break someones code, but.. its not great code to begin with and requires constant maintenance. - Hendrik _______________________________________________ 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".