Using __builtin_unwind_init in glibc

[Florian Weimer via Gcc]

I would like to use __builtin_unwind_init in glibc in a few places, to
preserve additional evidence for a debugger.  It's currently not a
documented built-in function.  Would that still be okay.

(Most architectures will have probably benefit from a custom
register-preserving assembler trampoline, but __builtin_unwind_init
would still be very useful for generic code.)

Thanks,
Florian

Re: Should GCC warn about sizeof(flexible_struct)?

[Alejandro Colomar via Gcc]

Hi Richard,

On 2023-08-14 08:41, Richard Biener wrote:
> On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc
>  wrote:

[...]

>> How about some -Wfam-sizeof-arithmetic that would not warn about taking
>> sizeof(s) but would warn if that sizeof is used in any arithmetic?
> 
> There are probably many ways sizeof() plus arithmetic can yield a correct
> size for allocation.  After all _all_ uses of FAM requires allocation
> and there's
> no convenient standard way of calculating the required size (sizeof
> (fam-type[n])?).

You may be confusing sizeof(struct contains_fam) with sizeof(fam[n]).

Yes, the second is necessary for allocation, but the first is not.  Well,
it is valid for allocation but only because allocating extra bytes is not
a problem.

The size of a flexible structure is calculated as the sum of the offset
of the fam, and the size of the fam.  The size of the structure has nothing
to do.

struct s {
int   i;
char  c;
char  fam[];
} s;

size = offsetof(struct s, fam) + sizeof("foobar"));  // OK: 12 B

size = sizeof(struct s) + sizeof("foobar"));  // NOK: 15 B; wastes bytes
   ^~~~ problem here.

> 
> Iff we want to diagnose anything then possibly a computation that looks like
> a size computation but that's actually smaller than required,

It's actually the other way around.  The problem is that the computation may
give a value larger than the expected one.  This can be usually a benign bug
and nothing bad will happen.  But when a programmer relies on that size for
reading or writing, which I've seen happen, you better make sure that the
structure has no padding, or you'll be reading/writing at `fam + padding`.

Example, using the allocation above:

strcpy((char *) s + sizeof(struct s), "foobar");  // NOK, writes after 
padding
puts(s->fam);  // OK, reads the fam, but surprise

// Unpredictable; prints 3 uninitialized bytes, then (if no previous 
'\0') "foobar"

strcpy(s->fam, "foobar");  // OK, writes at the fam
puts((char *) s + sizeof(struct s));  // NOK, reads after padding

// prints: "bar"

strcpy(s->fam, "foobar");  // OK
puts((char *) s + offsetof(struct s, fam));  // OK; with offsetof, 
equivalent to s->fam

// prints: "foobar"

strcpy((char *) s + offsetof(struct s, fam), "foobar");  // Also OK
puts(s->fam);  // OK

// prints: "foobar"

> but
> other than that - what
> would you suggest to fix such reported warnings?

To fix the warnings, replace all invocations of `sizeof(struct contains_fam)`
by `offsetof(struct contains_fam, fam)`.

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature

Re: Should GCC warn about sizeof(flexible_struct)?

[Martin Uecker]

Am Montag, dem 14.08.2023 um 11:51 +0200 schrieb Alejandro Colomar via Gcc:
> Hi Richard,
> 
> On 2023-08-14 08:41, Richard Biener wrote:
> > On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc
> >  wrote:
> 
> [...]
> 
> > > How about some -Wfam-sizeof-arithmetic that would not warn about taking
> > > sizeof(s) but would warn if that sizeof is used in any arithmetic?
> > 
> > There are probably many ways sizeof() plus arithmetic can yield a correct
> > size for allocation.  After all _all_ uses of FAM requires allocation
> > and there's
> > no convenient standard way of calculating the required size (sizeof
> > (fam-type[n])?).
> 
> You may be confusing sizeof(struct contains_fam) with sizeof(fam[n]).
> 
> Yes, the second is necessary for allocation, but the first is not.  Well,
> it is valid for allocation but only because allocating extra bytes is not
> a problem.
> 
> The size of a flexible structure is calculated as the sum of the offset
> of the fam, and the size of the fam.  The size of the structure has nothing
> to do.
> 
>   struct s {
>   int   i;
>   char  c;
>   char  fam[];
>   } s;
> 
>   size = offsetof(struct s, fam) + sizeof("foobar"));  // OK: 12 B
> 
>   size = sizeof(struct s) + sizeof("foobar"));  // NOK: 15 B; wastes bytes
>  ^~~~ problem here.
> 

The first formula may give a result smaller than sizeof(struct s), so
could also be dangerous.

Martin



> > 
> > Iff we want to diagnose anything then possibly a computation that looks like
> > a size computation but that's actually smaller than required,
> 
> It's actually the other way around.  The problem is that the computation may
> give a value larger than the expected one.  This can be usually a benign bug
> and nothing bad will happen.  But when a programmer relies on that size for
> reading or writing, which I've seen happen, you better make sure that the
> structure has no padding, or you'll be reading/writing at `fam + padding`.
> 
> Example, using the allocation above:
> 
>   strcpy((char *) s + sizeof(struct s), "foobar");  // NOK, writes after 
> padding
>   puts(s->fam);  // OK, reads the fam, but surprise
> 
>   // Unpredictable; prints 3 uninitialized bytes, then (if no previous 
> '\0') "foobar"
> 
>   strcpy(s->fam, "foobar");  // OK, writes at the fam
>   puts((char *) s + sizeof(struct s));  // NOK, reads after padding
> 
>   // prints: "bar"
> 
>   strcpy(s->fam, "foobar");  // OK
>   puts((char *) s + offsetof(struct s, fam));  // OK; with offsetof, 
> equivalent to s->fam
> 
>   // prints: "foobar"
> 
>   strcpy((char *) s + offsetof(struct s, fam), "foobar");  // Also OK
>   puts(s->fam);  // OK
> 
>   // prints: "foobar"
> 
> > but
> > other than that - what
> > would you suggest to fix such reported warnings?
> 
> To fix the warnings, replace all invocations of `sizeof(struct contains_fam)`
> by `offsetof(struct contains_fam, fam)`.
> 
> Cheers,
> Alex
> 

Re: Should GCC warn about sizeof(flexible_struct)?

[Qing Zhao via Gcc]

> On Aug 14, 2023, at 2:41 AM, Richard Biener via Gcc  wrote:
> 
> On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc
>  wrote:
>> 
>> Hi!
>> 
>> Structures with flexible array members have restrictions about being
>> used in arrays or within other structures, as the size of the enclosing
>> aggregate type would be... inconsistent.
>> 
>> In general, sizeof(flexible_struct) is a problematic thing that rarely
>> means what programmers think it means.  It is not the size of the
>> structure up to the flexible array member; or expressed using C,
>> the following can be true:
>> 
>>sizeof(s) != offsetof(s, fam)
>> 
>> See the program at the bottom that demonstrates how this is problematic.
>> 
>> It's true that if one uses
>> 
>>malloc(offseof(s, fam) + sizeof_member(s, fam[0]) * N);
>> 
>> and N is very small (0 or 1 usually), the allocation would be smaller
>> than the object size, which for GCC seems to be fine, but I'm worried the
>> standard is not clear enough about its validity[1].
>> 
>> [1]: 
>> 
>> To avoid having UB there, pedantically one would need to call
>> 
>>malloc(MAX(sizeof(s), offseof(s, fam) + sizeof_member(s, fam[0]) * 
>> N));
>> 
>> But I think that's the only correct use of sizeof() with structures
>> containing flexible array members.  So it seems sizeof() by itself is
>> a valid thing, but when adding it to something else to get the total size,
>> or doing any arithmetic with it, that's dubious code.
>> 
>> How about some -Wfam-sizeof-arithmetic that would not warn about taking
>> sizeof(s) but would warn if that sizeof is used in any arithmetic?
> 
> There are probably many ways sizeof() plus arithmetic can yield a correct
> size for allocation.  After all _all_ uses of FAM requires allocation
> and there's
> no convenient standard way of calculating the required size (sizeof
> (fam-type[n])?).
> 
> Iff we want to diagnose anything then possibly a computation that looks like
> a size computation but that's actually smaller than required,

Yes, I think that an warning on insufficient allocation might be useful in 
general, 
which might be combined with Martin’s previous proposed patch together: 
-Walloc_type?
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625172.html

Another thing is: is there a place in GCC’s doc where we can add some 
clarification
or suggestion to the users on how to allocate space for structures with FAM?
Looks like that this is a very confusion area..

thanks.

Qing

> but
> other than that - what
> would you suggest to fix such reported warnings?
> 
> Richard.
> 
>> Cheers,
>> Alex
>> 
>> ---
>> 
>> $ cat off.c
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> 
>> 
>> struct s {
>>int   i;
>>char  c;
>>char  fam[];
>> };
>> 
>> 
>> static inline void *xmalloc(size_t size);
>> 
>> 
>> int
>> main(void)
>> {
>>char  *p;
>>struct s  *s;
>> 
>>printf("sizeof: %zu\n", sizeof(struct s));
>>printf("offsetof: %zu\n", offsetof(struct s, fam));
>> 
>>puts("\nWith sizeof():");
>> 
>>s = xmalloc(sizeof(struct s) + sizeof("Hello, sizeof!"));
>>strcpy(s->fam, "Hello, sizeof!");
>>p = (char *) s + sizeof(struct s);
>>puts(p);
>>free(s);
>> 
>>puts("\nWith offsetof(3):");
>> 
>>s = xmalloc(offsetof(struct s, fam) + sizeof("Hello, offsetof!"));
>>strcpy(s->fam, "Hello, offsetof!");
>>p = (char *) s + offsetof(struct s, fam);
>>puts(p);
>>free(s);
>> 
>>exit(EXIT_SUCCESS);
>> }
>> 
>> 
>> static inline void *
>> xmalloc(size_t size)
>> {
>>void  *p;
>> 
>>p = malloc(size);
>>if (p == NULL)
>>err(EXIT_FAILURE, "malloc");
>>return p;
>> }
>> $ gcc-13 -Wall -Wextra -Wpadded -fanalyzer off.c
>> off.c:12:1: warning: padding struct size to alignment boundary with 3 bytes 
>> [-Wpadded]
>>   12 | };
>>  | ^
>> 
>> 
>> The only warning I know that is triggered in the code above is -Wpadded,
>> which is related to this problem, but I think there should be something
>> to warn about sizeof() in this context.
>> 
>> 
>> --
>> 
>> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

Re: Should GCC warn about sizeof(flexible_struct)?

[Alejandro Colomar via Gcc]

Hi Martin,

On 2023-08-14 18:49, Martin Uecker wrote:
> Am Montag, dem 14.08.2023 um 12:21 +0200 schrieb Alejandro Colomar:
[...]

>> Would you mind chiming in to this question?:
>> 
> 
> Unclear. It is probably UB by omission.

Agree.

>  But this is possibly
> different from the FAM case.

I don't think I agree on this.  To me it really looks like the same thing.
BTW, there was a mention there to the FAM case in a comment:


> 
> I any case, I am not so concerned about the whether this UB, 
> but that a programmer might do:
> 
> struct s = { .. }
> struct s* p = malloc(...)
> memcpy(p, &s, sizeof s); // copy header. 

That's (or could be) a bug, and just another manifestation of why
sizeof(s) is wrong.  Let's see a couple of ways how this can go wrong:


$ cat memcpy.c 
#include 
#include 
#include 

struct s {
int   i;
char  c;
char  fam[];
};

struct h {
int   i;
char  c;
};

int
main(void)
{
char  *f;
struct h  h = { .i = 42, .c = 3 };
struct s  *p;

p = malloc(sizeof(struct s) + sizeof("foobar"));

strcpy(p->fam, "foobar");
/*
 * since we're copying the header, it shouldn't matter if we
 * copy it after copying the fam itself, no?  They're at
 * different locations... or are they?
 */
memcpy(p, &h, sizeof(struct s));
puts(p->fam);
free(p);

p = malloc(sizeof(struct s) + sizeof("foobar"));

f = mempcpy(p, &h, sizeof(struct s));
/*
 * We could reuse the pointer from mempcpy(3) to get the location
 * of just after the header, right?  Heh.
 */
strcpy(f, "foobar");
puts(p->fam);
free(p);
}
$ cc -Wall -Wextra memcpy.c -D_GNU_SOURCE
$ ./a.out 


$


Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature

Re: Should GCC warn about sizeof(flexible_struct)?

[Alejandro Colomar via Gcc]

On 2023-08-14 19:11, Alejandro Colomar wrote:
> Hi Martin,
> 
> On 2023-08-14 18:49, Martin Uecker wrote:
>> Am Montag, dem 14.08.2023 um 12:21 +0200 schrieb Alejandro Colomar:
> [...]
> 
>>> Would you mind chiming in to this question?:
>>> 
>>
>> Unclear. It is probably UB by omission.
> 
> Agree.
> 
>>  But this is possibly
>> different from the FAM case.
> 
> I don't think I agree on this.  To me it really looks like the same thing.
> BTW, there was a mention there to the FAM case in a comment:
> 
> 
>>
>> I any case, I am not so concerned about the whether this UB, 
>> but that a programmer might do:
>>
>> struct s = { .. }
>> struct s* p = malloc(...)
>> memcpy(p, &s, sizeof s); // copy header. 
> 
> That's (or could be) a bug, and just another manifestation of why
> sizeof(s) is wrong.  Let's see a couple of ways how this can go wrong:
> 
> 
> $ cat memcpy.c 
> #include 
> #include 
> #include 
> 
> struct s {
>   int   i;
>   char  c;
>   char  fam[];
> };
> 
> struct h {
>   int   i;
>   char  c;
> };
> 
> int
> main(void)
> {
>   char  *f;
>   struct h  h = { .i = 42, .c = 3 };
>   struct s  *p;
> 
>   p = malloc(sizeof(struct s) + sizeof("foobar"));
> 
>   strcpy(p->fam, "foobar");
>   /*
>* since we're copying the header, it shouldn't matter if we
>* copy it after copying the fam itself, no?  They're at
>* different locations... or are they?
>*/
>   memcpy(p, &h, sizeof(struct s));

But if you did here

memcpy(p, &h, offsetof(struct s, fam));

>   puts(p->fam);
>   free(p);
> 
>   p = malloc(sizeof(struct s) + sizeof("foobar"));
> 
>   f = mempcpy(p, &h, sizeof(struct s));

and here

f = mempcpy(p, &h, offsetof(struct s, fam));

Then it magically works as expected:

$ ./a.out 
foobar
foobar


>   /*
>* We could reuse the pointer from mempcpy(3) to get the location
>* of just after the header, right?  Heh.
>*/
>   strcpy(f, "foobar");
>   puts(p->fam);
>   free(p);
> }
> $ cc -Wall -Wextra memcpy.c -D_GNU_SOURCE
> $ ./a.out 
> 
> 
> $
> 
> 
> Cheers,
> Alex
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature

Оставьте, пожалуйста, отзыв

[COINSTART via Gcc]

Здравствуйте, уважаемый клиент! Спасибо, что доверяете нам!

А Вы знали что у нас проходит розыгрыш денежного приза!? 💵

Условия очень простые:
- Оставьте, пожалуйста, положительный отзыв на BestChange по данной ссылке: 
https://bestchange.ru/coinstart-exchanger.html
- Подтвердите отзыв по ссылке в письме, которое поступит от мониторинга 
BestChange.

Каждый положительный отзыв участвует в денежном розыгрыше

Подробнее о розыгрыше https://coinstart.cc/contest

Не упустите возможность принять участие и забрать выигрыш🏅

С Уважением,
Команда Coinstart!