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 6B63F42348 for ; Mon, 13 Jun 2022 13:17:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4AB2068B5CB; Mon, 13 Jun 2022 16:17:38 +0300 (EEST) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B5D7168B19F for ; Mon, 13 Jun 2022 16:17:31 +0300 (EEST) Received: by mail-qk1-f169.google.com with SMTP id l192so1803774qke.13 for ; Mon, 13 Jun 2022 06:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=/dAehBgrBUIIR0erjA+7QDhD6+fh63fc3MsOBb82Z+Y=; b=MGzPGdvkFDUYwUFcdsHqwRQ15svXQUqai23pGGAz2amtKtLEIU7mIct+ixO0QtH7uH L1p6XHG7v76nP0t12CADh01o+wliVKzHWAYQpV2VwT3mTcuYiZ7UOHAL6zsW68LW09Q4 H1LOQ+eox4A+cnOdtMMNF8hZ7Q5VHGPwKG5phy/R3MCpvG1Nn7dBc1D87FGb1aY8YjSV zf3eUlAInjI1ESyDAUJLel0lm0+hNyYKziVYZpG+9Iu/A//1jI1G2VYg4qT5NXpbauFr mvWi5utv+U0BPdalbnJWv3nHPZBcGQBP1NrQgQsn4Vutx9e75Z8IUIEj3aj78TgSV2zF y7Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=/dAehBgrBUIIR0erjA+7QDhD6+fh63fc3MsOBb82Z+Y=; b=VgyOQaTtYF/m2+PgTJzej8RZxv06JbZfTo5pIsienR0mtYCGxn7BtUBCxaTrPJ6wI3 PP3OqxTtImOkbZa6BP1ny7qJM+bljx03IiFe8aE87iv7B0szCYrtsLeSdubOlPqwLyDN gjGbcUqns/aw6f6Jmkse/btN5L7UVylPnyxoNe4KnTQYgn7VkYdxIAa8KsfKTJ248vbx R4wdQ8OXHr4k7ywaOXa/hAeNuza6Bcd2NXiTeLcVdFO2NTUupmb2SFStJx781IeAJSfA mnIoHghGfqjn6ZVOOmAV2QD3+a9C45d8bcbxCU87ICaO0B78vPrRDuUG+XndLnMZLpFb i6wg== X-Gm-Message-State: AOAM530yXHRnlsf+vaEHqzvbmJdqfTJVijFPoV3MLZlmmCdF8mTzkDQk ig96RL3msRoEO9RS1G9c+2kUHXbib4I= X-Google-Smtp-Source: ABdhPJyrOTRF2kNphvJR9498W3GokQnL8US2QPS3shBISkymDGq8bF/zuvqo7Ti5xWVG8A3O0xOFkg== X-Received: by 2002:a37:a781:0:b0:6a6:9b4c:fc8d with SMTP id q123-20020a37a781000000b006a69b4cfc8dmr35056776qke.657.1655126250154; Mon, 13 Jun 2022 06:17:30 -0700 (PDT) Received: from [192.168.1.35] (c-68-41-54-207.hsd1.mi.comcast.net. [68.41.54.207]) by smtp.gmail.com with ESMTPSA id bl35-20020a05620a1aa300b006a6c552736asm6414542qkb.119.2022.06.13.06.17.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jun 2022 06:17:29 -0700 (PDT) Message-ID: Date: Mon, 13 Jun 2022 09:17:29 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US-large To: ffmpeg-devel@ffmpeg.org References: <20220611140820.105906-1-leo.izen@gmail.com> From: Leo Izen In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: declare VLC table args as const 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 6/12/22 16:01, Andreas Rheinhardt wrote: > Leo Izen: >> Declaring the VLC table as const allows a caller to call get_vlc2() >> with a pre-generated static const table without generating warnings >> for -Wdiscarded-qualifiers. >> --- >> libavcodec/get_bits.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h >> index d4e9276da1..49202b0211 100644 >> --- a/libavcodec/get_bits.h >> +++ b/libavcodec/get_bits.h >> @@ -775,7 +775,7 @@ static inline const uint8_t *align_get_bits(GetBitContext *s) >> >> /* Return the LUT element for the given bitstream configuration. */ >> static inline int set_idx(GetBitContext *s, int code, int *n, int *nb_bits, >> - VLC_TYPE (*table)[2]) >> + const VLC_TYPE (*table)[2]) >> { >> unsigned idx; >> >> @@ -795,7 +795,7 @@ static inline int set_idx(GetBitContext *s, int code, int *n, int *nb_bits, >> * = (max_vlc_length + bits - 1) / bits >> * @returns the code parsed or -1 if no vlc matches >> */ >> -static av_always_inline int get_vlc2(GetBitContext *s, VLC_TYPE (*table)[2], >> +static av_always_inline int get_vlc2(GetBitContext *s, const VLC_TYPE (*table)[2], >> int bits, int max_depth) >> { >> #if CACHED_BITSTREAM_READER > > There is unfortunately an issue here: C11 6.7.3/9 contains the > following: "If the specification of an array type includes any type > qualifiers, the element type is so-qualified, not the array type." > > Therefore adding const above means that the functions accept a > pointer-to-array-of-two-const-VLC_TYPE, but ordinary callers call this with > a pointer-to-array-of-two-VLC_TYPE; the automatic conversion from > pointer-to-T to pointer-to-const-T does not help you here, because it > would only give you a pointer-to-const-array-of-two-VLC_TYPE, but not a > pointer-to-an-array-of-two-const-VLC_TYPE; at least that is the > prevailing interpretation of the above part of the spec (I don't get why > one does not just use 6.7.3/9 once more to conclude that > pointer-to-const-array-of-two-VLC_TYPE is actually equivalent to > pointer-to-array-of-const-VLC_TYPE). > Older versions of GCC warned by default for such conversions (when using > an ISO standard -- it is legal in GNU C standards); current versions > still do so when compiling with -pedantic. Clang does not warn about > this at all, not even with -pedantic. > > I see three ways to fix this: > a) Add a get_vlc2c that accepts const. It will have the implementation > of the current get_vlc2; get_vlc2 meanwhile would be turned into a > wrapper for get_vlc2c, i.e. it would solely be used to cast to the > expected pointer type. > b) Add the necessary casts in the only user that wants to use a const table. > c) Stop using VLC_TYPE[2] altogether; use a struct { VLC_TYPE symbol, > bits; } (it feels like this struct should actually be called VLC_TYPE). > Then adding const works fine as usual; it would IMO be more readable, > too, because it would be automatically documented which of the entries > is what. This is therefore my preferred option. Would you mind if I > implemented this or do you want to do it? > > - Andreas I would not mind if you implemented this. Thank you, I appreciate it. - Leo Izen (thebombzen) _______________________________________________ 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".