Possible bug in FpDebug lazarus / 12-Debugger ---------------------------------------------------------------------- 440bx · 2024-11-13 01:57 Hello, FPC v3.2.2 & Lazarus v3.99 (2024-10-23) Consider the following code:Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$APPTYPE CONSOLE} program _WatchEnums; uses  Windows  ; type  {$PACKENUM 1}    TDATA_TYPE =                                  { prefix: dt_               }    (     dt_not_examined = 0,     dt_unknown,      dt_code_first,     dt_code_last,      dt_data_first,     dt_data_last,     { make the filler and markers easy to recognize by setting their numeric  }    { values to easily identifiable numbers                                   }      dt_pe_filler_first   = 240,           { filler is supposed to be       }       dt_pe_filler_code,                  { inaccessible                   }       dt_pe_filler_data,     dt_pe_filler_last,      dt_markers_first     = 250,       dt_marker_bottom,                 { bottom message map sentinel      }       dt_marker_top,                    {    top    "     "     "          }     dt_markers_last    );   {$PACKENUM 4} type  TRECORD = record    field_value : DWORD;    field_type  : TDATA_TYPE;     field_info  : array[0..5] of DWORD;  end; function  AFunction : boolean;var  Table : array[0..9] of TRECORD;   ti    : DWORD = 0; begin  result := FALSE;   ZeroMemory(@Table, sizeof(Table));   for ti := 0 to 3 do  begin    with Table[ti] do    begin      field_value   := ti;      Field_info[0] := ti;       case ti of        0    : field_type := dt_marker_bottom;         1, 2 : field_type := dt_pe_filler_code;       3    : field_type := dt_marker_top;      end;    end;  end;   result := TRUE;end; begin  AFunction();   readln;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 · 2024-11-13 15:21 Please report. Please copy the below to the report. The issue is that fpc treats the enum as signed Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type  TFoo= (f1=1, f2=$FFFFFFFF); gives Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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 · 2024-11-13 15:37 This may be really tricky to fix.... Maybe not at all. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1;{$PackEnum 1}type  Tfoo = (f1=-1, f2=255);var  a,b: TFoo;begin  a:= f1;  b:= f2;  b:= f2;end.  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 · 2024-11-13 15:44 There is another issue ... https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41240 But that does not affect the display you have ---------------------------------------------------------------------- Martin_fr · 2024-11-13 15:50 https://lists.freepascal.org/pipermail/fpc- devel/2024-November/045825.html ---------------------------------------------------------------------- 440bx · 2024-11-14 06:18 Quote from: Martin_fr on November 13, 2024, 04:21:26 pmThe 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 · 2024-11-17 15:39 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 · 2024-11-17 16:25 Quote from: Martin_fr on November 17, 2024, 04:39:18 pmJust 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.