Possible bug in FpDebug

[440bx]

Hello,

FPC v3.2.2 & Lazarus v3.99 (2024-10-23)

Consider the following code:

Code: Pascal  [Select][+][-]

1. {$APPTYPE CONSOLE}
2.  
3. program _WatchEnums;
4.  
5. uses
6.   Windows
7.   ;
8.  
9. type
10.   {$PACKENUM 1}
11.     TDATA_TYPE =                                  { prefix: dt_               }
12.     (
13.      dt_not_examined = 0,
14.      dt_unknown,
15.  
16.      dt_code_first,
17.      dt_code_last,
18.  
19.      dt_data_first,
20.      dt_data_last,
21.  
22.     { make the filler and markers easy to recognize by setting their numeric  }
23.     { values to easily identifiable numbers                                   }
24.  
25.      dt_pe_filler_first   = 240,           { filler is supposed to be         }
26.        dt_pe_filler_code,                  { inaccessible                     }
27.        dt_pe_filler_data,
28.      dt_pe_filler_last,
29.  
30.      dt_markers_first     = 250,
31.        dt_marker_bottom,                   { bottom message map sentinel      }
32.        dt_marker_top,                      {    top    "     "     "          }
33.      dt_markers_last
34.     );
35.  
36.   {$PACKENUM 4}
37.  
38. type
39.   TRECORD = record
40.     field_value : DWORD;
41.     field_type  : TDATA_TYPE;
42.  
43.     field_info  : array[0..5] of DWORD;
44.   end;
45.  
46. function  AFunction : boolean;
47. var
48.   Table : array[0..9] of TRECORD;
49.  
50.   ti    : DWORD = 0;
51.  
52. begin
53.   result := FALSE;
54.  
55.   ZeroMemory(@Table, sizeof(Table));
56.  
57.   for ti := 0 to 3 do
58.   begin
59.     with Table[ti] do
60.     begin
61.       field_value   := ti;
62.       Field_info[0] := ti;
63.  
64.       case ti of
65.         0    : field_type := dt_marker_bottom;
66.  
67.         1, 2 : field_type := dt_pe_filler_code;
68.  
69.         3    : field_type := dt_marker_top;
70.       end;
71.     end;
72.   end;
73.  
74.   result := TRUE;
75. end;
76.  
77. begin
78.   AFunction();
79.  
80.   readln;
81. end.                                          

When watching the values of the "Table" array, the values of "field_type" are not as expected.

field_type is defined to be of type TDATA_TYPE which consists of all positive constants yet the watch window shows the values assigned to "field_type" to be negative.  (please see attachment.)

Is the compiler posting incorrect symbols for TDATA_TYPE or is the debugger (FpDebug) misinterpreting them ?

it would be nice if the values in the watch window were as they are defined in the data type, i.e, 240 241 instead of -15, 250 251 instead of -5 and 251 252 instead of -4.

comments welcome.

ETA:

Added forgotten attachment.

Corrected the expected values which were originally off by one in the text.

[Martin_fr]

Please report.

Please copy the below to the report.

The issue is that fpc treats the enum as signed

Code: Pascal  [Select][+][-]

1. type
2.   TFoo= (f1=1, f2=$FFFFFFFF);
3.  

gives

Code: Text  [Select][+][-]

1. project1.lpr(7,28) Error: Enumeration symbols can only have values in the range of -2^31 to 2^31-1

Your enum has a value of $FF

FPC marks it as being a 1 byte sized value. => so the debugger sees it has -1.

But fpc does write the value as a 4 byte constant 000000FF.
And for a 1 byte enum with actually -1 it writes the constant FFFFFFFF.


That may also differ between fpc versions.

[Martin_fr]

This may be really tricky to fix.... Maybe not at all.

Code: Pascal  [Select][+][-]

1. program Project1;
2. {$PackEnum 1}
3. type
4.   Tfoo = (f1=-1, f2=255);
5. var
6.   a,b: TFoo;
7. begin
8.   a:= f1;
9.   b:= f2;
10.   b:= f2;
11. end.
12.  

Both variables have the value $FF

There is no way the debugger can tell if $FF is -1 or 255


So if we have a 1 byte value. And if enums are generally signed...
Then if the debugger finds $FF that is -1

[Martin_fr]

There is another issue ... https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41240

But that does not affect the display you have

[Martin_fr]

https://lists.freepascal.org/pipermail/fpc-devel/2024-November/045825.html

[440bx]

The issue is that fpc treats the enum as signed

yes and it does that even in cases where the enum cannot be signed.

[Martin_fr]

Just found: https://gitlab.com/freepascal.org/fpc/source/-/issues/41019

Afaik, the enum is always signed.

So if you use any value between 128 and 255 as ordinal for one of the enums then it should be a 2 byte enum. (because it does not fit into s_int8).

But documentation is not giving any details / not that I have found.

[440bx]

Just found: https://gitlab.com/freepascal.org/fpc/source/-/issues/41019

Afaik, the enum is always signed.

So if you use any value between 128 and 255 as ordinal for one of the enums then it should be a 2 byte enum. (because it does not fit into s_int8).

But documentation is not giving any details / not that I have found.

I think that for consistency the size in bytes should be determined by the ranges used to define data types. IOW, 0..255 =  uint8/byte, -128..127 = int8/shortint, anything outside those ranges uses additional bytes as needed by standard FPC data types, e.g -1..255 = int16 (2 bytes)

IOW, the signedness should be determined by the enumeration's values (their range) not by compiler assumptions.