mycc built-in field_sizeof(), sizeof struct field

[DiTBho]

so, in in mycc it's a build-in operator since the end of 2022

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!

[Nominal Animal]

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!

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; })

[SiliconWizard]

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.

[DiTBho]

Code: [Select]

         mystring_clean(query_item[i0].mape, file_query_item_t.name'size);
2024/5/16: now, mycc can do this 

[DiTBho]

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.

[S. Petrukhin]

Is SizeOf(file_query_item_t.name ) doesn't work?

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

[DiTBho]

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!

[DiTBho]

Code: [Select]

         mystring_clean(query_item[i0].mape, file_query_item_t.name'size);
2024/5/16: now, mycc can do this 

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

[ejeffrey]

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.

[SiliconWizard]

Code: [Select]

         mystring_clean(query_item[i0].mape, file_query_item_t.name'size);
2024/5/16: now, mycc can do this 

"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.

[S. Petrukhin]

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.