Okay, Based on the comments so far, I will work on the 5th version of the
patch, major changes will include:
1. Change the return type of the routine .ACCESS_WITH_SIZE
FROM:
Pointer to the type of the element of the flexible array;
TO:
Pointer to the type of the flexible
> On Jan 30, 2024, at 12:41 AM, Kees Cook wrote:
>
> On Mon, Jan 29, 2024 at 10:45:23PM +, Qing Zhao wrote:
>> There are two things here.
>>
>> 1. The value of the “counted-by” is 0; (which is easy to be understood)
>> 2. The result of the _builtin_object_size when see a “counted-by” 0.
On Mon, Jan 29, 2024 at 10:45:23PM +, Qing Zhao wrote:
> There are two things here.
>
> 1. The value of the “counted-by” is 0; (which is easy to be understood)
> 2. The result of the _builtin_object_size when see a “counted-by” 0.
>
> For 1, it’s simple, if we see a counted-by value <= 0,
> On Jan 29, 2024, at 3:19 PM, Kees Cook wrote:
>
> On Mon, Jan 29, 2024 at 07:32:06PM +, Qing Zhao wrote:
>>
>>
>>> On Jan 29, 2024, at 12:25 PM, Kees Cook wrote:
>>>
>>> On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote:
An update on the kernel building with my version 4
> On Jan 29, 2024, at 3:35 PM, Joseph Myers wrote:
>
> On Mon, 29 Jan 2024, Qing Zhao wrote:
>
>> Thank you!
>>
>> Joseph and Richard, could you also comment on this?
>
> I think Martin's suggestions are reasonable.
Okay, I will update the patches based on this approach.
Thanks a lot
On Mon, 29 Jan 2024, Qing Zhao wrote:
> Thank you!
>
> Joseph and Richard, could you also comment on this?
I think Martin's suggestions are reasonable.
--
Joseph S. Myers
josmy...@redhat.com
On Mon, Jan 29, 2024 at 07:32:06PM +, Qing Zhao wrote:
>
>
> > On Jan 29, 2024, at 12:25 PM, Kees Cook wrote:
> >
> > On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote:
> >> An update on the kernel building with my version 4 patch.
> >>
> >> Kees reported two FE issues with the
> On Jan 29, 2024, at 12:25 PM, Kees Cook wrote:
>
> On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote:
>> An update on the kernel building with my version 4 patch.
>>
>> Kees reported two FE issues with the current version 4 patch:
>>
>> 1. The operator “typeof” cannot return
On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote:
> An update on the kernel building with my version 4 patch.
>
> Kees reported two FE issues with the current version 4 patch:
>
> 1. The operator “typeof” cannot return correct type for a->array;
> 2. The operator “&” cannot return
> On Jan 29, 2024, at 10:50 AM, Martin Uecker wrote:
>
> Am Montag, dem 29.01.2024 um 15:09 + schrieb Qing Zhao:
>> Thank you!
>>
>> Joseph and Richard, could you also comment on this?
>>
>>> On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote:
>>>
>>> Am Freitag, dem 26.01.2024 um 14:33
An update on the kernel building with my version 4 patch.
Kees reported two FE issues with the current version 4 patch:
1. The operator “typeof” cannot return correct type for a->array;
2. The operator “&” cannot return correct address for a->array;
I fixed both in my local repository.
With
Am Montag, dem 29.01.2024 um 15:09 + schrieb Qing Zhao:
> Thank you!
>
> Joseph and Richard, could you also comment on this?
>
> > On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote:
> >
> > Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao:
> > >
> > > > On Jan 26, 2024, at 3:04
Thank you!
Joseph and Richard, could you also comment on this?
> On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote:
>
> Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao:
>>
>>> On Jan 26, 2024, at 3:04 AM, Martin Uecker wrote:
>>>
>>>
>>> I haven't looked at the patch, but it
Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao:
>
> > On Jan 26, 2024, at 3:04 AM, Martin Uecker wrote:
> >
> >
> > I haven't looked at the patch, but it sounds you give the result
> > the wrong type. Then patching up all use cases instead of the
> > type seems wrong.
>
> Yes,
> On Jan 26, 2024, at 3:04 AM, Martin Uecker wrote:
>
>
> I haven't looked at the patch, but it sounds you give the result
> the wrong type. Then patching up all use cases instead of the
> type seems wrong.
Yes, this is for resolving a very early gimplification issue as I reported last
Nov:
I haven't looked at the patch, but it sounds you give the result
the wrong type. Then patching up all use cases instead of the
type seems wrong.
Martin
Am Donnerstag, dem 25.01.2024 um 20:11 + schrieb Qing Zhao:
> Thanks a lot for the testing.
>
> Yes, I can repeat the issue with the
Thanks a lot for the testing.
Yes, I can repeat the issue with the following small example:
#include
#include
#include
#define MAX(a, b) ((a) > (b) ? (a) : (b))
struct untracked {
int size;
int array[] __attribute__((counted_by (size)));
} *a;
struct untracked * alloc_buf
On Wed, Jan 24, 2024 at 12:29:51AM +, Qing Zhao wrote:
> This is the 4th version of the patch.
Thanks very much for this!
I tripped over an unexpected behavioral change that the Linux kernel
depends on:
__builtin_types_compatible_p() no longer treats an array marked with
counted_by as
Hi,
This is the 4th version of the patch.
It based on the following proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635884.html
Represent the missing dependence for the "counted_by" attribute and its
consumers
**The summary of the proposal is:
* Add a new internal
19 matches
Mail list logo
