Messages in this thread |  | | From | Andreas Gruenbacher <> | | Date | Tue, 25 Nov 2025 11:39:34 +0100 | | Subject | Re: [PATCH] fs: rework I_NEW handling to operate without fences |
| |
On Tue, Nov 25, 2025 at 4:01 AM Mateusz Guzik <mjguzik@gmail.com> wrote: > On Tue, Nov 25, 2025 at 12:04 AM Andreas Gruenbacher > <agruenba@redhat.com> wrote: > > > > On Mon, Nov 24, 2025 at 8:25 PM Mateusz Guzik <mjguzik@gmail.com> wrote: > > > On Mon, Nov 24, 2025 at 6:47 PM Andreas Gruenbacher <agruenba@redhat.com> wrote: > > > > > > > > On Sat, Oct 11, 2025 at 12:17 AM Mateusz Guzik <mjguzik@gmail.com> wrote: > > > Was that always a thing? My grep for '!!' shows plenty of hits in the > > > kernel tree and I'm pretty sure this was an established pratice. > > > > It depends on the data type. The non-not "operator" converts non-0 > > values into 1. For boolean values, that conversion is implicit. For > > example, > > > > !!0x100 == 1 > > (bool)0x100 == 1 > > > > but > > > > (char)0x100 == 0 > > > > I mean it was an established practice *specifically* for bools. > > Case in point from quick grep on the kernel: > /* Internal helper functions to match cpu capability type */ > static bool > cpucap_late_cpu_optional(const struct arm64_cpu_capabilities *cap) > { > return !!(cap->type & ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU); > } > > static bool > cpucap_late_cpu_permitted(const struct arm64_cpu_capabilities *cap) > { > return !!(cap->type & ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU); > } > > static bool > cpucap_panic_on_conflict(const struct arm64_cpu_capabilities *cap) > { > return !!(cap->type & ARM64_CPUCAP_PANIC_ON_CONFLICT); > } > > I suspect the practice predates bool support in the C standard and > people afterwards never found out.
Yes, often it's simply not needed anymore.
Andreas
|  |