Re: [Tarantool-patches] [PATCH luajit 1/2] build: introduce LUAJIT_USE_UBSAN option

[Maxim Kokryashkin via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Hi, Sergey!
See my answer below.

On Mon, May 27, 2024 at 10:22:08AM UTC, Sergey Kaplun wrote:
> Hi, Maxim!
> Thanks for the review!
>
> On 26.05.24, Maxim Kokryashkin wrote:
> > Hi, Sergey!
> > See my thoughts below.
> >
> > On Thu, May 16, 2024 at 01:14:14PM UTC, Sergey Kaplun wrote:
> > > Hi, folks!
> > > Some more thoughts below.
> > >
> > > On 15.05.24, Sergey Kaplun wrote:
> > >
> > > <snipped>
> > >
> > > > +  string(JOIN "," UBSAN_IGNORE_OPTIONS
> > > > +    # Misaligned pseudo-pointers are used to determine internal
> > > > +    # variable names inside the `for` cycle.
> > > > +    alignment
> > > > +    # Not interested in float cast overflow errors.
> > > > +    float-cast-overflow
> > > > +    # NULL checking is disabled because this is not a UB and
> > > > +    # raises lots of false-positive fails.
> > > > +    null
> > >
> > > Maybe it is worth to add also "nonnull-attribute" to the ignore options:
> > >
> > > ```
> > > LSAN_OPTIONS="abort_on_error=1" src/luajit -e 'error("bad usage", 3)'
> > > /home/burii/builds_workspace/luajit/gh-8473-ubsan/src/lj_buf.h:75:25: runtime error: null pointer passed as argument 1, which is declared to never be null
> > > /usr/include/string.h:44:28: note: nonnull attribute specified here
> > > ```
> > >
> > > Here, `memcpy()` gets the NULL pointer as the first argument and the
> > > `len` == 0. So there are no problems here. Also, the nullability
> > > violation is not a UB, as mentioned in the documentation.
> >
> > It is UB, though: https://en.cppreference.com/w/cpp/string/byte/memcpy
> > Even with the zero len it may still cause issues, so I don't think we
> > should disable this check.
>
> But there are no such words in the `memcpy` man page. The only one
> mentioned UB is about overlapping memory chunks. Also, I suppose that
> the first point applies only to the case, when the bytes are actually
> copied (i.e., when size is not zero).

Here is the standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
And it states clearly:

| 7.24.1 String function conventions
...
| 2. Where an argument declared as size_t n specifies the length of the array for a function, n can have
| the value zero on a call to that function. Unless explicitly stated otherwise in the description of a
| particular function in this subclause, pointer arguments on such a call shall still have valid values, as
| described in 7.1.4. On such a call, a function that locates a character finds no occurrence, a function
| that compares two character sequences returns zero, and a function that copies characters copies
| zero characters.

The 7.1.4.1 then states:
| Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow:
| — If an argument to a function has an invalid value (such as a value outside the domain of the
| function, or a pointer outside the address space of the program, or a null pointer, or a pointer
| to non-modifiable storage when the corresponding parameter is not const-qualified) or a type
| (after default argument promotion) not expected by a function with a variable number of
| arguments, the behavior is undefined.

So it is UB after all.

Side note: if a function is able to accept a NULL-pointer, then the man
page usually has its signature written like this:
| int accept(int sockfd, struct sockaddr *_Nullable restrict addr,
|                  socklen_t *_Nullable restrict addrlen);

`_Nullable` before a parameter name here means that it can be a
NULL-pointer safely.

>
> >
> > > Thoughts?
> > >
> > > > +    # Not interested in checking arithmetic with NULL.
> > > > +    pointer-overflow
> > > > +    # Shifts of negative numbers are widely used in parsing ULEB,
> > > > +    # cdata arithmetic, vmevent hash calculation, etc.
> > > > +    shift-base
> > > > +  )
> > >
> > > --
> > > Best regards,
> > > Sergey Kaplun
>
> --
> Best regards,
> Sergey Kaplun