linux-kernel - Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator after the loop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 27 Feb 2022 05:32:45 -0600
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     David Laight <David.Laight@...lab.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jakob <jakobkoschel@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Mike Rapoport <rppt@...nel.org>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Brian Johannesmeyer <bjohannesmeyer@...il.com>,
        Cristiano Giuffrida <c.giuffrida@...nl>,
        "Bos, H.J." <h.j.bos@...nl>
Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator after the loop

On Sun, Feb 27, 2022 at 07:10:45AM +0000, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 27 February 2022 01:10
> > On Sat, Feb 26, 2022 at 11:14:15PM +0100, Arnd Bergmann wrote:
> > > On Sat, Feb 26, 2022 at 1:42 PM Segher Boessenkool
> > > <segher@...nel.crashing.org> wrote:
> > > > The only reason the warning exists is because it is undefined behaviour
> > > > (not implementation-defined or anything).  The reason it is that in the
> > > > standard is that it is hard to implement and even describe for machines
> > > > that are not two's complement.  However relevant that is today :-)
> 
> I thought only right shifts of negative values were 'undefined'.

All shifts by a negative amount, or an amount greater or equal to the
width of the first operand (after the integer promotions).

Right shifts of a negative value.

Left shifts of a negative value where E1*2**E2 is not expressable in the
result type.

C90 (aka C89) had those right shifts merely implementation-defined
behaviour, and the left shifts perfectly well-defined.

> And that was to allow cpu that only had logical shift right
> (ie ones that didn't propagate the sign) to be conformant.

The C99 rationale says
  The C89 Committee affirmed the freedom in implementation granted by
  K&R in not requiring the signed right shift operation to sign extend,
  since such a requirement might slow down fast code and since the
  usefulness of sign extended shifts is marginal. (Shifting a negative
  two’s-complement integer arithmetically right one place is not the
  same as dividing by two!)

> I wonder when the last cpu like that was?

There still are one-off cores without such an instruction.  If you have
right shifts at all (if you have shifts at all!) it quickly becomes
apparent what a hassle it is not to have an SRA/ASR/SAR instruction, and
it is easy to implement, so :-)

The last widely spread ones' complement machine was the 6600 I guess,
which disappeared somewhere in the 80's.  Sign-magnitude machines are
still made: all FP is like that, and some (simple, embedded, etc.)
machines have no separate integer register set.  C is available for most
such fringe CPUs :-)

> Quite why the standards keeps using the term 'undefined behaviour'
> beats me - there ought to be something for 'undefined value'.

It is pretty much impossible to not have *some* undefined behaviour.
How will you define dividing by zero so that its behaviour is reasonable
for every program, for example?  Invoking an error handler at runtime
has most of the same unwanted effects, except is is never silent.  You
can get that via UBSAN for example.  Defining some arbitrary value as
the "correct" answer when that is not at all obvious *does* give silent,
unexpected results.

C does have "unspecified value"s and "unspecified behaviour".  It
requires the implementation to document the choice made here.  At least
some effort was made not to have undefined behaviour everywhere.

Perhaps C does have the concept you are after in 6.3.2/2, where it talks
about using uninitialised objects?  Of course, using an uninitialised
object is undefined behaviour :-P

C has much more undefined behaviours than most other languages.  On one
hand there was no clear, formal definition of the language (and
testsuites for it etc.) before it became popular.  On the other hand, it
was implemented on widely different architectures, back in the days when
there was a lot more variety in implementation choices than there is
now.  When the language was standardised (and all the way to this day)
the sentiment was to not unnecessarily break existing implementations.

Segher