#4148 _Optional analysis does not retain a checked structure member's non-nullness

[Christopher Bazley]

I wasn't sure whether this should be filed as a bug or a feature request. Feel free to recategorise it but either way it is effectively blocking use of _Optional in one of my projects because the troublesome pattern is so common and the workaround is somewhat onerous.

1: Sample code that reproduces the problem.

struct S
{
  _Optional int *p;
};

int read_value(struct S *s)
{
  if (s->p)
    return *s->p;
  return 0;
}

2: Exact command used to run SDCC on this sample code

sdcc -mz80 --std-c99 -c repro.c

3: SDCC version tested

SDCC trunk r16999.

4: Copy of the error message or incorrect output, or a clear description of the observed versus expected behavior.

warning 355: pointer to _Optional could not be proven to be non-null at dereference

I expected no diagnostic at *s->p: the member has just been checked, is not volatile, and there is no intervening assignment or function call.

Copying the member's value to a local pointer before checking it avoids the warning:

int read_value(struct S *s)
{
  _Optional int *p = s->p;
  if (p)
    return *p;
  return 0;
}

The same results occur with z80, mcs51, r2k, stm8, s08 and pdk14. Equivalent guards on *pp and on a file-scope pointer produce no warning. This therefore appears specific to the repeated structure-member access.

Possibly related to #3957, but this example has no intervening indirect assignment. The warning occurs at the first dereference after the guard.

[Christopher Bazley]

Here's the sample code in Compiler Explorer, demonstrating the issue as it manifests with SDCC 4.6.0: https://godbolt.org/z/cveYebarj

[Christopher Bazley]

Apparently there is also a secondary issue, where volatile is not respected wrt. a struct member access.

[Christopher Bazley]

I'm attaching a candidate fix for the issue reported here. Thevolatile bug will need to be reported and fixed separately.

[Philipp Klaus Krause]

The functionality of the patch looks ok to me. But that comment is confusing. Maybe rephrase as "casts from pointers do not depend on signedness of the source"? A cast from char to a pointer type does depend on the signedness of the source.
I think the patch can go in with the comment changed.