From: Peter Zijlstra
> Sent: 14 April 2022 16:21
...
> <snip tons of noise>
>
..
> > -#define sched_class_highest (__end_sched_classes - 1)
> > +/*
> > + * sched_class_highests is really __end_sched_classes - 1, but written in a way
> > + * that makes it clear that it is within __begin_sched_classes[] and not outside
> > + * of __end_sched_classes[].
> > + */
> > +#define sched_class_highest (__begin_sched_classes + \
> > + (__end_sched_classes - __begin_sched_classes - 1))
> > #define sched_class_lowest (__begin_sched_classes - 1)
> >
> > +/* The + 1 below places the pointers within the range of their array */
> > #define for_class_range(class, _from, _to) \
> > - for (class = (_from); class != (_to); class--)
> > + for (class = (_from); class + 1 != (_to) + 1; class--)
That is still technically broken because you are still calculating
the address of array[-1] - even though it is probably optimised out.
> Urgh, so now we get less readable code, just because GCC is being
> stupid?
>
> What's wrong with negative array indexes? memory is memory, stuff works.
Consider segmented x86 where malloc() always returns {segment:0..segment:size).
Pointer arithmetic will only change the offset.
So &array[-1] is likely to be greater than &array[0].
So it has never been valid C to create pointers to before a data item.
OTOH I've NFI why gcc and clang have started generating warnings for
portability issues that really don't affect mainstream systems.
I'm just waiting for them to warn about memset(p, 0 sizeof *p) when
the structure contains pointers - because the NULL pointer doesn't
have to be the all-zero bit pattern.
The only reason (int)&(struct foo *)0->member is non-portable is because
NULL might not be 0.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
