[fpc-devel] Record types with unbounded trailing data

[J. Gareth Moreton]

Thought I'd ask.  Nothing lost.  Just seeking a consensus on how to 
address the problem.

Gareth

On 24/06/2019 05:41, Michael Van Canneyt wrote:
>
>
> On Mon, 24 Jun 2019, J. Gareth Moreton wrote:
>
>> Hi everyone,
>>
>> So after a problem over at 
>> https://bugs.freepascal.org/view.php?id=35753 that led to a change of 
>> https://bugs.freepascal.org/view.php?id=35671 , it became apparent 
>> that there may need to be better support for unbounded arrays in 
>> record types - not open arrays, but unbounded ones.
>>
>
> [snip]
>
>>
>> It's a lot to think about for sure, and is probably overengineering a 
>> solution to a very niche problem (I personally can't think of where 
>> one would use such constructs instead of something with a fixed-size 
>> array or just having the header and open array stored separarely), 
>> but is it worth discussing?
>
> No. This *really* is overengineering.
>
> If you declare what is clearly a dummy structure, then tricks will be 
> needed. Disabling range checks on such constructs and warnings is the 
> only sensible thing to do.
>
> If you want to get rid of warnings, define it as
> LOGPALETTE = record
>    palVersion : WORD;
>    palNumEntries : WORD;
>    palPalEntry : array[0..(MAXINT div sizeof(PALETTEENTRY)] of 
> PALETTEENTRY;
> end;
>
> Since you will always work through a getmem'ed memory block & pointer 
> anyway, and
> all bets are off in that case. There is simply no point in letting the
> compiler check anything extra since the construct is by definition 
> uncheckable.
>
> Michael.
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190624/b2829232/attachment.html>