Forum > FPC development
FPC feature request/suggestion
MarkMLl:
--- Quote from: 440bx on June 29, 2022, 12:21:07 pm ---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.
--- End quote ---
I think that I'd argue is that you should use a case statement, and only support fixed-size data structures (i.e. preceded by an API-version-specific length) where the particular API version has been tested.
Otherwise, where the data structure is not fixed length (i.e. is preceded by a varying length field like a Pascal string) I don't see the problem.
MarkMLl
440bx:
--- Quote from: MarkMLl on June 29, 2022, 12:42:45 pm ---I think that I'd argue is that you should use a case statement, and only support fixed-size data structures
--- End quote ---
It's not that simple. Consider you have a library of API definitions, MS adds a few fields to some structure, you add them to your definitions to keep up to date. Now the problem is this, if the code is using "sizeof(<the record>)" then it will be using the new larger record size and the existing code may or may not work correctly with a larger structure, that's why limiting to a specific field is important. Otherwise, those additional fields would force the programmer to review _every_ program that uses that record to ensure it is not affected by the new size.
By making the record size specific to one field then older code can be updated as needed or when convenient instead of, at least in some cases, breaking.
Also, when translating headers, the two things that really matter are the offsets of each field (particularly when some of them have specific alignment requirements) and the record size up to and including a particular field. If memory serves, the MS common controls library is full of "variations" based on record sizes. It's really inconvenient not having a simple, clear and straightforward way of determining field offsets and record sizes up to and including a field.
Those missing features in FPC'/Delphi also make verifying that structures are translated correctly from C to Pascal very tedious and laborious.
MarkMLl:
--- Quote from: 440bx on June 29, 2022, 01:21:41 pm ---additional fields would force the programmer to review _every_ program that uses that record to ensure it is not affected by the new size.
--- End quote ---
That's right.
What you should be asking for is some form of annotation, possibly related to Lazarus's TODO, which can be applied to anything declared to mimic a non-Pascal API or data structure.
MarkMLl
alpine:
--- Quote from: 440bx on June 29, 2022, 12:21:07 pm ---
--- 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.
--- End quote ---
Do you mean something like:
--- Code: C [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---typedef struct { int field; int field2; // added in v2 of the api int field3; // added in v3 of the api} apistruct, *papistruct; void APIfunc( papistruct arg, size_t arglen ) // latest api{ arg->field = 1; if( arglen > offsetof( apistruct, field2 ) ) // v2 of the api? arg->field2 = 2; if( arglen > offsetof( apistruct, field3 ) ) // v3 of the api? arg->field3 = 3;} // ... and in the api calling application:// (presumably built when api was < v3 and apistruct was shorter) apistruct s; APIfunc( &s, sizeof( apistruct ) ); // call the recent APIfunc() with older version of apistruct Or you mean something different?
Because I'm not using the proposed sizeof( apistruct, field3 ) above.
--- Quote from: 440bx on June 29, 2022, 12:21:07 pm ---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.
--- End quote ---
That will be impossible at runtime without some sort of introspection or linker/debugger symbol table. IMO that is not what you're asking for, i.e. compile-time sizeof(<record name>, <record field name>).
--- Quote from: 440bx on June 29, 2022, 12:21:07 pm ---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.
--- End quote ---
I still don't get it. Why showing offsets and sizes of structs defined in C headers from FPC? Patching something? BTW one of the few cases I used offsetof() in C was when I wrote patching of configuration structures in a micro-controller NV memory where it can be written by single words but only erased in bulk.
And what's wrong with offsetof(a, b) + sizeof(b) compared to sizeof(a, b)?
Navigation
[0] Message Index
[*] Previous page