| Message ID | CAB0OVGo9jgwppRKLLJfACwdtUx0745H+EC+jkmUv_bV+Ly7w7A@mail.gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [FFmpeg-devel] lavc/sbc: Remove bool usage | expand |
| Context | Check | Description |
|---|---|---|
| andriy/ffmpeg-patchwork | success | Make fate finished |
On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > Hi! > > It seems to me that this was forgotten when the codec was originally > ported. > why removing "stdbool.h"? it was defined in 2001? so, most compiler should support it.. Should we not check for the compiler support of it and if not, then either reject the compiler or defines the type ourself? > > Please comment, Carl Eugen > _______________________________________________ > 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".
On 4/1/20, Thierry Foucu <tfoucu@gmail.com> wrote: > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >> Hi! >> >> It seems to me that this was forgotten when the codec was originally >> ported. >> > > why removing "stdbool.h"? > it was defined in 2001? so, most compiler should support it.. > Should we not check for the compiler support of it and if not, then either > reject the compiler or defines the type ourself? You are deeply wrong. > > > >> >> Please comment, Carl Eugen >> _______________________________________________ >> 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". > > > > -- > > Thierry Foucu > _______________________________________________ > 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".
Am Mi., 1. Apr. 2020 um 23:23 Uhr schrieb Thierry Foucu <tfoucu@gmail.com>: > > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > > Hi! > > > > It seems to me that this was forgotten when the codec was originally > > ported. > > > > why removing "stdbool.h"? We never liked it (and I am sure there are examples of rejected patches), in this particular case, looking at the code, it was just an oversight when cleaning the code of bool. > it was defined in 2001? > so, most compiler should support it.. I hope you find the most important word in your sentence;-) > Should we not check for the compiler support of it and if not, then either > reject the compiler or defines the type ourself? It seems significantly easier to avoid it. Carl Eugen
On Thu, 2 Apr 2020 at 08:53, Paul B Mahol <onemda@gmail.com> wrote: > On 4/1/20, Thierry Foucu <tfoucu@gmail.com> wrote: > > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: > > > >> Hi! > >> > >> It seems to me that this was forgotten when the codec was originally > >> ported. > >> > > > > why removing "stdbool.h"? > > it was defined in 2001? so, most compiler should support it.. > > Should we not check for the compiler support of it and if not, then > either > > reject the compiler or defines the type ourself? > > You are deeply wrong. > What modern compiler does not support bool? Kieran
On 4/2/20, Kieran Kunhya <kierank@obe.tv> wrote: > On Thu, 2 Apr 2020 at 08:53, Paul B Mahol <onemda@gmail.com> wrote: > >> On 4/1/20, Thierry Foucu <tfoucu@gmail.com> wrote: >> > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> >> wrote: >> > >> >> Hi! >> >> >> >> It seems to me that this was forgotten when the codec was originally >> >> ported. >> >> >> > >> > why removing "stdbool.h"? >> > it was defined in 2001? so, most compiler should support it.. >> > Should we not check for the compiler support of it and if not, then >> either >> > reject the compiler or defines the type ourself? >> >> You are deeply wrong. >> > > What modern compiler does not support bool? > I do not care, bool is evil and should never be used. > Kieran > _______________________________________________ > 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".
On 02/04/2020 10:41, Paul B Mahol wrote:
> I do not care, bool is evil and should never be used.
Why? 'We don't like it' isn't a technical reason.
Also, FFmpeg already uses plenty of C99 features and thus
requires a C99 compiler. What is so inherently evil about a boolean
type that it must not be allowed, but other C99 features are?
I am curious what compilers support all the C99 features used that
do not support stdbool.h, and are still actually used (even by 2 people).
- Derek
On 4/2/20, Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote: > On 02/04/2020 10:41, Paul B Mahol wrote: >> I do not care, bool is evil and should never be used. > > Why? 'We don't like it' isn't a technical reason. > > Also, FFmpeg already uses plenty of C99 features and thus > requires a C99 compiler. What is so inherently evil about a boolean > type that it must not be allowed, but other C99 features are? > > I am curious what compilers support all the C99 features used that > do not support stdbool.h, and are still actually used (even by 2 people). No code in FFmpeg use it. And it was disallowed before and should be now. > > - Derek > _______________________________________________ > 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".
On 02/04/2020 14:24, Paul B Mahol wrote: > No code in FFmpeg use it. > And it was disallowed before and should be now. 'Because we've always done it that way' is not a valid technical argument. - Derek
On Thu, 2 Apr 2020 at 14:24, Paul B Mahol <onemda@gmail.com> wrote: > On 4/2/20, Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote: > > On 02/04/2020 10:41, Paul B Mahol wrote: > >> I do not care, bool is evil and should never be used. > > > > Why? 'We don't like it' isn't a technical reason. > > > > Also, FFmpeg already uses plenty of C99 features and thus > > requires a C99 compiler. What is so inherently evil about a boolean > > type that it must not be allowed, but other C99 features are? > > > > I am curious what compilers support all the C99 features used that > > do not support stdbool.h, and are still actually used (even by 2 people). > > No code in FFmpeg use it. > And it was disallowed before and should be now. > https://en.wikipedia.org/wiki/Appeal_to_tradition Kieran
Paul B Mahol (12020-04-02): > No code in FFmpeg use it. > And it was disallowed before and should be now. There are many features that were not used and have become used when the need happened. Named initializers, for example. Compound literals. If there are no actual practical arguments against bool, from either you or somebody else, then I suggest we leave this one as it is and no longer reject patches based on this.
On 4/2/20, Nicolas George <george@nsup.org> wrote: > Paul B Mahol (12020-04-02): >> No code in FFmpeg use it. >> And it was disallowed before and should be now. > > There are many features that were not used and have become used when the > need happened. Named initializers, for example. Compound literals. > > If there are no actual practical arguments against bool, from either you > or somebody else, then I suggest we leave this one as it is and no > longer reject patches based on this. > It is pointless discussion. I gonna commit this patch NOW. Certainly I will reject any patch with bool in any code that I maintain. > -- > Nicolas George > _______________________________________________ > 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".
On Thu, Apr 02, 2020 at 15:33:02 +0200, Nicolas George wrote: > If there are no actual practical arguments against bool, from either you > or somebody else, then I suggest we leave this one as it is and no > longer reject patches based on this. I though this was the practical argument?: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html http://trac.ffmpeg.org/ticket/8591 Moritz
Am Do., 2. Apr. 2020 um 18:53 Uhr schrieb Moritz Barsnick <barsnick@gmx.net>: > > On Thu, Apr 02, 2020 at 15:33:02 +0200, Nicolas George wrote: > > If there are no actual practical arguments against bool, from either you > > or somebody else, then I suggest we leave this one as it is and no > > longer reject patches based on this. > > I though this was the practical argument?: > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > http://trac.ffmpeg.org/ticket/8591 The argument for my patch in this thread is only that when the sbc files were originally cleaned of bool, one occurrence was forgotten. Carl Eugen
On 02/04/2020 17:47, Moritz Barsnick wrote: > I though this was the practical argument?: > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > http://trac.ffmpeg.org/ticket/8591 It isn't really clear to me what the actual problem is from the description - how is bool fundementally different on PPC? (Sorry, I am not familiar with PPC...) - Derek
On Thu, Apr 2, 2020 at 11:11 AM Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote: > On 02/04/2020 17:47, Moritz Barsnick wrote: > > I though this was the practical argument?: > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > > http://trac.ffmpeg.org/ticket/8591 > > It isn't really clear to me what the actual problem is from the > description - how is bool fundementally different on PPC? > Seems other project have the same problem with PPC64EL https://mails.dpdk.org/archives/dev/2018-August/110281.html but that was in 2018.. > > (Sorry, I am not familiar with PPC...) > > - Derek > _______________________________________________ > 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".
On Thu, Apr 2, 2020 at 11:18 AM Thierry Foucu <tfoucu@gmail.com> wrote: > > > On Thu, Apr 2, 2020 at 11:11 AM Derek Buitenhuis < > derek.buitenhuis@gmail.com> wrote: > >> On 02/04/2020 17:47, Moritz Barsnick wrote: >> > I though this was the practical argument?: >> > >> > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html >> > http://trac.ffmpeg.org/ticket/8591 >> >> It isn't really clear to me what the actual problem is from the >> description - how is bool fundementally different on PPC? >> > > Seems other project have the same problem with PPC64EL > https://mails.dpdk.org/archives/dev/2018-August/110281.html > > but that was in 2018.. > And here is the patch they used to fix it: https://mails.dpdk.org/archives/dev/2018-August/110485.html > > >> >> (Sorry, I am not familiar with PPC...) >> >> - Derek >> _______________________________________________ >> 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". > > > > -- > > Thierry Foucu >
Am Do., 2. Apr. 2020 um 20:11 Uhr schrieb Derek Buitenhuis <derek.buitenhuis@gmail.com>: > > On 02/04/2020 17:47, Moritz Barsnick wrote: > > I though this was the practical argument?: > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > > http://trac.ffmpeg.org/ticket/8591 > > It isn't really clear to me what the actual problem is from the > description - how is bool fundementally different on PPC? bool is defined as a vector on ppc altivec unless you tell the compiler not to (which most likely has other side-effects). But this is unrelated to the patch posted here. Carl Eugen
On 02/04/2020 19:23, Thierry Foucu wrote: > And here is the patch they used to fix it: > https://mails.dpdk.org/archives/dev/2018-August/110485.html Interesting... Altivec isn't standards compliant? TIL. - Derek
Derek Buitenhuis (12020-04-02):
> Interesting... Altivec isn't standards compliant? TIL.
What I read is Apple isn't standards compliant. I knew that.
This fix seems harmless enough.
Regards,
On 02/04/2020 19:52, Nicolas George wrote: > What I read is Apple isn't standards compliant. I knew that. > > This fix seems harmless enough. The fix in the linked archive? I agree. - Derek
Am Do., 2. Apr. 2020 um 20:52 Uhr schrieb Nicolas George <george@nsup.org>: > > Derek Buitenhuis (12020-04-02): > > Interesting... Altivec isn't standards compliant? TIL. > > What I read is Apple isn't standards compliant. I knew that. "Apple" as in the people who launched ppc64el Linux? Can we stop this? Carl Eugen
Am Mi., 1. Apr. 2020 um 21:30 Uhr schrieb Carl Eugen Hoyos <ceffmpeg@gmail.com>:
> It seems to me that this was forgotten when the codec was originally ported.
Patch applied.
Carl Eugen
From 3077d14fed1c19afbcdfd8282fac2a7f1bf3492d Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos <ceffmpeg@gmail.com> Date: Wed, 1 Apr 2020 21:28:09 +0200 Subject: [PATCH] lavc/sbc: Remove bool usage. --- libavcodec/sbcdec.c | 1 - libavcodec/sbcenc.c | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/libavcodec/sbcdec.c b/libavcodec/sbcdec.c index 2ebde46627..5361ee2c89 100644 --- a/libavcodec/sbcdec.c +++ b/libavcodec/sbcdec.c @@ -30,7 +30,6 @@ * SBC decoder implementation */ -#include <stdbool.h> #include "avcodec.h" #include "internal.h" #include "libavutil/intreadwrite.h" diff --git a/libavcodec/sbcenc.c b/libavcodec/sbcenc.c index e2929e22ac..631acf7905 100644 --- a/libavcodec/sbcenc.c +++ b/libavcodec/sbcenc.c @@ -30,7 +30,6 @@ * SBC encoder implementation */ -#include <stdbool.h> #include "libavutil/opt.h" #include "avcodec.h" #include "internal.h" @@ -95,7 +94,7 @@ static int sbc_analyze_audio(SBCDSPContext *s, struct sbc_frame *frame) * Returns the length of the packed frame. */ static size_t sbc_pack_frame(AVPacket *avpkt, struct sbc_frame *frame, - int joint, bool msbc) + int joint, int msbc) { PutBitContext pb; -- 2.24.1