> On Nov 19, 2024, at 16:36, Martin Uecker <uec...@tugraz.at> wrote:
>
> Am Montag, dem 18.11.2024 um 21:31 +0000 schrieb Qing Zhao:
>>
>>> On Nov 18, 2024, at 13:10, Martin Uecker <uec...@tugraz.at> wrote:
>>
> ...
>> So, I guess that the more accurate question is, for the following:
>>
>> struct annotated {
>> int b;
>> int *c __attribute__ ((counted_by (b)));
>> } *p_array_annotated;
>>
>> p_array_annotated->c[10] = 2;
>>
>>
>> Should we treat the reference “p_array_annotated->c[10]” as
>> an array reference if the pointer field “c” in the “struct annotated”
>> has the counted_by attribute?
>
> Assuming UBSan is they way to go, then yes and I agree
> that after casting to another type this should not be
> done anymore.
At this moment, I think that using “counted_by” attribute attached to the
pointer field in the current
UBsan might be a reasonable and practical approach.
If we get more request for a new option -fboundscheck without dependence on the
shared C++ library,
We might need spend more time for that separate task.
Currently, as I know, GCC provides the following options:
-fisolate-erroneous-paths-dereference ¶
Detect paths that trigger erroneous or undefined behavior due to dereferencing
a null pointer. Isolate those paths from the main control flow and turn the
statement with erroneous or undefined behavior into a trap. This flag is
enabled by default at -O2 and higher and depends on
-fdelete-null-pointer-checks also being enabled.
-fisolate-erroneous-paths-attribute
Detect paths that trigger erroneous or undefined behavior due to a null value
being used in a way forbidden by a returns_nonnull or nonnull attribute.
Isolate those paths from the main control flow and turn the statement with
erroneous or undefined behavior into a trap. This is not currently enabled, but
may be enabled by -O2 in the future.
From my understanding, the new option -fboundscheck as you proposed is similar
to the above two options, is my understanding correct?
>
>>
>>>
>>> I am a bit frustrated about the sanitizer. On the
>>> one hand, it is not doing enough to get spatial memory
>>> safety even where this would be easily possible, on the
>>> other hand, is pedantic about things which are technically
>>> UB but not problematic and then one is prevented from
>>> using it.
>>
>> Yes, In order to make sanitizer better, both the above issues need to be
>> addressed.
>>>
>>> When used in default mode, where execution continues, it
>>> also does not mix well with many warning, creates more code,
>>> and pulls in a libary dependency (and the library also depends
>>> on upstream choices / progress which seems a limitation for
>>> extensions).
>>
>> Right, all these are existing issues with the current sanitizer.
>>>
>>> What IMHO would be ideal is a protection mode for spatial
>>> memory safety that simply adds traps (which then requires
>>> no library, has no issues with other warnings, and could
>>> evolve independently from clang)
>>>
>>> So shouldn't we just add a -fboundscheck (which would
>>> be like -fsanitize=bounds -fsanitize-trap=bounds just with
>>> more checking) and make it really good? I think many people
>>> would be very happy about this.
>>
>> Then why not just fix the known issues in the current
>> -fsanitize=bounds -fsanitize-trap=bounds to make it better?
>> What’s the major benefit to add another new option?
>
> The question is how to fix this?
>
> At the moment the sanitizer is tied to a shared C++ library
> maintained elsewhere (I believe) with a design that ties
> every specific case to a specific entry point in this library.
>
> So the UBsan handlers become part of an ABI that needs to
> be maintained and upgraded. Also you need to reimplement
> this when using it somewhere we you can't have a C++ library.
> (I assume kernels or embedded platforms have all their
> own implementations). If we add something, everything
> needs to be upgraded. For 'counted_by' and 'bounds' you
> may get a way with the existing message.
Okay, I see, Yes, that’s really a problem.
Thanks for your explanation.
Qing
>
>
> Martin
