On Mon, 2024-07-22 at 17:54 +0100, Joern Wolfgang Rennecke wrote:
>
>
> On 22/07/2024 17:13, Joern Wolfgang Rennecke wrote:
> > I guess you could reduce the differences between platforms if you
> didn't
> > use types as defined by headerfiles directly, as they might be
> > #defines
> > or typedefs or whatever, and instead used your own typedef or
> > struct types.
>
> It seems a typedef to int is seen through, even if you chain two of
> them
> together.
> After preprocessing, newlib has:
>
> typedef long int __int32_t;
>
> typedef __int32_t int32_t ;
>
> So the crucial point seems to be to have 'long int', but that is of
> course not portable for int32_t.
>
> So to get portable code and consistent messages, I suppose we should
> use
> a struct:
>
> typedef struct { int32_t i; } my_int32;
> my_int32 s42 = { 42 };
> my_int32 *buf = (my_int32 *) __builtin_alloca (4 * size + 3); /* {
> dg-warning "allocated buffer size is not a multiple of the pointee's
> size" } */
> buf[size] = s42; /* { dg-warning "stack-based buffer overflow" }
> */
>
> Now suddenly the diagram is made *more* verbose, with the struct
> keyword
> added.
>
> ┌─────────────────────────────────────────────┐
> │ write of ‘struct my_int32’ (4
> bytes) │
>
> └─────────────────────────────────────────────┘
> │ │
> │ │
> v v
> ┌───────────────────────────────────────┐
> ┌────────────────────────┐
> │ buffer allocated on stack at (1) │ │ after valid
> range │
> └───────────────────────────────────────┘
> └────────────────────────┘
> ├───────────────────┬───────────────────┤
> ├───────────┬────────────┤
> │ │
> ╭────────────────┴───────────────╮
> ╭─────────┴────────╮
> │capacity: ‘(size * 4) + 3’ bytes│ │overflow of 1
> byte│
> ╰────────────────────────────────╯
> ╰──────────────────╯
>
Sorry, I didn't see this followup before sending my last email.
I like this approach, as I don't care about exactly what the wording in
that upper-right box is, just the wording towards the bottom of the
diagram.
Thanks
Dave
