Author Topic: mycc built-in field_sizeof(), sizeof struct field  (Read 484 times)

0 Members and 1 Guest are viewing this topic.

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3957
  • Country: gb
mycc built-in field_sizeof(), sizeof struct field
« on: May 16, 2024, 09:55:28 am »
so, in in mycc it's a build-in operator since the end of 2022 :D :D :D

Code: [Select]
2022/12/20 query/lib_file_query_v1.c:        mystring_clean(query_item[i0].name, field_sizeof(file_query_item_t, name));
2022/12/20 query/lib_file_query_v1.c:        mystring_clean(query_item[i0].mape, field_sizeof(file_query_item_t, mape));
(first time I needed something like this, probably a silly case ...
... anyway it's when I put the functionality in the compiler
after that I started using it wherever it is needed/makes the code more clean)

Code: [Select]
typedef struct
{
    uint32_t  fp;
    char_t    name[file_query_item_name_size];
    char_t    mape[file_query_item_mape_size];
    uint32_t  flags;
    uint32_t  mode;
    boolean_t is_empty;
} file_query_item_t;
(xinu code)

field_sizeof(file_query_item_t, name)
             retuns file_query_item_name_size

field_sizeof(file_query_item_t, mape)
             retuns file_query_item_mape_size

it's a *very* usefult feature!

C/89 doesn't have it and in Linux you have to "emulate" it by this
Code: [Select]
#define field_sizeof(t, f) (sizeof(((t*)0)->f))

My opinion: this topic is informative, the field_sizeof() operator should be built-in in every C/C-like compiler! :D
« Last Edit: May 16, 2024, 09:59:51 am by DiTBho »
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6419
  • Country: fi
    • My home page and email address
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #1 on: May 16, 2024, 12:17:37 pm »
C/89 doesn't have it and in Linux you have to "emulate" it by this
Code: [Select]
#define field_sizeof(t, f) (sizeof(((t*)0)->f))
In the C23 standard, however, footnote 4 explicitly states that (void *)0 is valid in the operand of alignas, alignof, and sizeof expressions.  Thus, in C23,
    #define  field_sizeof(type, member)  (sizeof ((type *)0)->member)
can be understood/accepted as being valid (as long as member is not a variable length array at least).

There are also quite a few userspace users of that, and in definitions of the related offsetof macro,
    #define  offsetof(type, member)  ((size_t) &(((type *)0)->member))
so any compiler that cannot handle these will fail to compile quite lot of existing C code, too.

(It is important to remember that aside from C11, the C standard has evolved by including stuff compilers have implemented and users use; not by defining or dictating completely new features not implemented yet by any compiler.)

My opinion: this topic is informative, the field_sizeof() operator should be built-in in every C/C-like compiler! :D
Agreed.

GCC has traditionally implemented many related operators as an extension to C:
  • __alignof__, standardized in C11 as _Alignof and in C23 as alignof
  • __alignas__, standardized in C11 as _Alignas and in C23 as alignas
  • typeof, standardized in C23 as typeof (and typeof_unqual for the non-atomic unqualified type of the expression)
which are similarly useful.  typeof and compound statements in parentheses (another GCC extension) allow macros that only evaluate their parameters only once (as long as they are not variably modified types):
    #define  foo(x, y)  ({ typeof (x) _x = (x); typeof (y) _y = (y); use _x and _y ... ; result; })
 
The following users thanked this post: SiliconWizard, DiTBho

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14665
  • Country: fr
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #2 on: May 16, 2024, 11:04:08 pm »
Yes, all this has been available on many C compilers for a long time, but was not strictly allowed by the C standard until C23.
 

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3957
  • Country: gb
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #3 on: May 17, 2024, 01:09:59 pm »
Code: [Select]
         mystring_clean(query_item[i0].mape, file_query_item_t.name'size);
2024/5/16: now, mycc can do this  :o :o :o
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3957
  • Country: gb
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #4 on: May 17, 2024, 01:13:14 pm »
Yes, all this has been available on many C compilers for a long time, but was not strictly allowed by the C standard until C23.

Yup, the above trick (first post) is used in recent linux kernels, so I have already updated the builder database (which checks the environment before allowing the user to compile things) to make sure kernels and part of the Catalyst rootfs, which use the same trick, are compiled with the correct version of Gcc and right flags, in order to have C23 support.

The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline S. Petrukhin

  • Super Contributor
  • ***
  • Posts: 1270
  • Country: ru
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #5 on: May 17, 2024, 02:16:30 pm »
Is SizeOf(file_query_item_t.name ) doesn't work?

P.S. I don't know much about C.
And sorry for my English.
 

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3957
  • Country: gb
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #6 on: May 17, 2024, 05:48:16 pm »
SizeOf(file_query_item_t.name )

eh, if it was so intuitive ...
unfortunately it doesn't work like that, look at how the macro is made
Code: [Select]
#define field_sizeof(t, f) (sizeof(((t*)0)->f))
you pass the struct type (t), and then the field (f).

And it's already a miracle that it works.
e.g. on SierraC, and on AvgetC (90s), the macro doesn't work at all.

You need modern gcc/llvm, with C23 support!
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3957
  • Country: gb
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #7 on: May 17, 2024, 05:51:10 pm »
Code: [Select]
         mystring_clean(query_item[i0].mape, file_query_item_t.name'size);
2024/5/16: now, mycc can do this  :o :o :o

"mycc" is a compiler that I wrote; to achieve that result I had to completely change the approach.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3769
  • Country: us
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #8 on: May 17, 2024, 06:10:28 pm »
Is SizeOf(file_query_item_t.name ) doesn't work?

P.S. I don't know much about C.

 No in C you can't use the . or -> operators on a type name, only in a value expression.
 
The following users thanked this post: S. Petrukhin

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14665
  • Country: fr
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #9 on: May 17, 2024, 10:32:07 pm »
Code: [Select]
         mystring_clean(query_item[i0].mape, file_query_item_t.name'size);
2024/5/16: now, mycc can do this  :o :o :o

"mycc" is a compiler that I wrote; to achieve that result I had to completely change the approach.

So you have added attributes in the Ada style. That's cool.
 
The following users thanked this post: DiTBho

Offline S. Petrukhin

  • Super Contributor
  • ***
  • Posts: 1270
  • Country: ru
Re: mycc built-in field_sizeof(), sizeof struct field
« Reply #10 on: May 18, 2024, 09:35:58 am »
The mice pricked and cried, but continued to eat the cactus.  :)
I'm sorry, I remembered a joke...

Generating a type when describing a structure field is accessible, but ugly.
In addition to the fact that it is not possible to take the size of the structure field as a variable, there is a type checking conflict when passing this field as a variable to the function.

I think it will be more reliable and beautiful this way:
Code: [Select]
type
   name[file_query_item_name_size] name_t;
   nape[file_query_item_nape_size] nape_t;

typedef struct
{
    uint32_t  fp;
    name_t name;
    nape_t mape;
} file_query_item_t;

Having a name_t definition, you can use it when specifying function parameters and allow the compiler to check for compliance.
« Last Edit: May 18, 2024, 09:37:49 am by S. Petrukhin »
And sorry for my English.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf