Forum > FPC development

FPC feature request/suggestion

(1/2) > >>

440bx:
Hello,

In Windows, it's becoming quite common for structures to include a size field which the O/S uses at runtime to determine which fields it can set. 

It would be very nice if FPC supported a variant of "sizeof" where it could take a field name, i.e, sizeof(<record name>, <record field name>) yielding the size of the record up to and _including_ the field.

There is a way of doing it but, it is very unclean because, it requires using the name of the field that _follows_ the field of interest which makes it completely unclear what the last field to be included is.

Succinctly: a sizeof(<record name>, <record field name>)

It's might be worth noting that the compiler already has the necessary information in its symbol tables to implement this compile time facility.

Thank you for reading.

marcov:
You mean like https://gitlab.com/freepascal.org/fpc/source/-/issues/15416
 ?

Note that ptrint(@pstruct(nil).field) is a workaround.

440bx:

--- Quote from: marcov on June 29, 2022, 09:41:59 am ---You mean like https://gitlab.com/freepascal.org/fpc/source/-/issues/15416
 ?

--- End quote ---
That's the basic idea but, the offset of the field is _not_ the size of the record up to and including that field.  To obtain the size of the record, including the field, requires adding the size of the field to its offset.

As the posters in the feature request you linked to mentioned, that nil pointer dereference is not elegant and has a number of shortcomings.  It's, as you stated, a workaround and one that is not really clear nor very desirable.

The compiler has the offset of every record field in its symbol tables, it can easily return the offset of any field and the size of a record up to and including the field, what's missing is a simple and straightforward way of asking the compiler for that information.

OffsetOf(<record>, <field>) _and_ sizeof(<record>, <record field>) would be _very_ nice features to have.  In C, these capabilities are implemented with macros but, they cannot be implemented using FPC's macro facilities.

y.ivanov:

--- Quote from: 440bx on June 29, 2022, 04:36:51 am ---Hello,

In Windows, it's becoming quite common for structures to include a size field which the O/S uses at runtime to determine which fields it can set. 

It would be very nice if FPC supported a variant of "sizeof" where it could take a field name, i.e, sizeof(<record name>, <record field name>) yielding the size of the record up to and _including_ the field.

*snip*

--- End quote ---
Sure it will be nice, but for what is that needed for? I'm not getting it clearly from your first sentence.

440bx:

--- Quote from: y.ivanov on June 29, 2022, 11:31:22 am ---Sure it will be nice, but for what is that needed for? I'm not getting it clearly from your first sentence.

--- End quote ---
There are quite a few cases when it would be extremely convenient to have those features. 

The most common case is when a Windows structure has changed and Windows relies on the size to determine what to return (fill in).  If a program can use sizeof(<record>, <record field>) then fields added later don't affect how the code works.  IOW, the layout of the record can be updated without causing any potentially damaging side effects in existing code that uses that record.

Another case, less common, there are some programs that need to determine offsets and fields sizes at runtime, e.g, debuggers.  Without, OffsetOf and/or sizeof(<record>, <field>) writing the code is very laborious and tedious not to mention that maintaining the code becomes difficult.

Another case is when translating C headers.  In C, using the macros that are already in the headers, it is straightforward to create (even generate) a program that lists all the records along with their fields, including the field offset and size.  Doing that in Delphi/FPC is laborious and tedious, thereby making the verification that the translation is correct also tedious and time consuming.

OffsetOf(<record>, <field>) and sizeof(<record>, <field>) would _really_ make life _much_ simpler in a number of important cases.


Navigation

[0] Message Index

[#] Next page

Go to full version