View Issue Details

IDProjectCategoryView StatusLast Update
0036175FPCCompilerpublic2019-11-15 10:50
ReporterAkira1364 Assigned ToFlorian  
Status resolvedResolutionno change required 
Product Version3.3.1 
Summary0036175: No clear course of action for dealing with C / C++ header translations with enums that really are greater than 2147483647.
DescriptionI'm aware that this *technically* has never been valid (for reasons I'm not entirely clear about) in Pascal, but even if it would wrap around on the actual numerical value, FPC did at least display the "textual" name of these enums. For example:

program PascalExample;

  // ↓↓↓ reduced version of the actual enum for example purposes
  TVkAccessFlagBits = (
    VK_ACCESS_RESERVED_31_BIT_KHR = $80000000

would print exactly "VK_ACCESS_RESERVED_31_BIT_KHR".

More importantly though, it's not a "mistake" in the sense that it's just a literal, correct translation of the value from a C header, which in that context *is* valid, and doesn't outwardly seem like it should have any reason to *not* translate directly to Pascal. E.G. the C++ equivalent is completely fine and works correctly in all scenarios:

#include <iostream>

// ↓↓↓ reduced version of the actual enum for example purposes

enum TVkAccessFlagBits {
  VK_ACCESS_RESERVED_31_BIT_KHR = 0x80000000

int main() {
  // ↓↓↓ no wraparound, proper numerical value is preserved.
  std::cout << TVkAccessFlagBits::VK_ACCESS_RESERVED_31_BIT_KHR << std::endl;

I may be oversimplifying things, but it seems like something like a {$Z8} compiler switch would make more sense than just maintaining the somewhat arbitrary High(LongInt) cap, which evidently isn't quite compatible with everything it should be.
Steps To ReproduceCompile provided snippets, or similar code.
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0036315 resolvedZeljan Rikalo Lazarus Cannot compile Qt5 widgetset on last FPC trunk 



2019-10-14 21:31

administrator   ~0118603

Pascal enums are not C(++) enums. Having 8 byte enums will not help as it breaks binary compatiblity. That it worked before was by pure accident. It was (ab-)using an unchecked overflow in the compiler. The usefull woraround is to insert an explicit longint typecase for the constant.


2019-10-18 21:55

reporter   ~0118669

Last edited: 2019-10-18 21:56

View 3 revisions

The typecast does seem to make them compile again, and FPC still does print the text names in that case.

It seems the only way to preserve the actual numeric values is to move the fields out into standalone consts, however. I suppose there may never have been a way around that, though.

Marco van de Voort

2019-10-18 22:37

manager   ~0118671

Last edited: 2019-10-18 22:38

View 2 revisions

type TVkAccessFlagBits = (
    VK_ACCESS_RESERVED_31_BIT_KHR = dword($80000000)


works fine, and this is used a lot in e.g. Jedi headers (winunits-jedi). Printed ORD() value is negative though

Issue History

Date Modified Username Field Change
2019-10-14 04:18 Akira1364 New Issue
2019-10-14 21:31 Florian Note Added: 0118603
2019-10-18 21:55 Akira1364 Note Added: 0118669
2019-10-18 21:56 Akira1364 Note Edited: 0118669 View Revisions
2019-10-18 21:56 Akira1364 Note Edited: 0118669 View Revisions
2019-10-18 22:37 Marco van de Voort Note Added: 0118671
2019-10-18 22:38 Marco van de Voort Note Edited: 0118671 View Revisions
2019-11-02 17:32 Florian Assigned To => Florian
2019-11-02 17:32 Florian Status new => resolved
2019-11-02 17:32 Florian Resolution open => no change required
2019-11-02 17:32 Florian FPCTarget => -
2019-11-15 10:50 Sven Barth Relationship added related to 0036315