View Issue Details

IDProjectCategoryView StatusLast Update
0035118FPCRTLpublic2020-03-12 11:39
Reporter440bx Assigned ToMarco van de Voort  
Status assignedResolutionopen 
Product Version3.0.4 
Summary0035118: Kernel32's GetDateFormatEx and related constant definitions are missing.
DescriptionThe missing constants and definition are: (tested in both 32 and 64bit)

  LOCALE_NAME_USER_DEFAULT : pwidechar = nil;
  LOCALE_NAME_INVARIANT : pwidechar = '';
  LOCALE_NAME_SYSTEM_DEFAULT : pwidechar = '!x-sys-default-locale';

{ NOTE: there is no ANSI version of this function, only unicode/wide }

function GetDateFormatEx(LocaleName : pwidechar;
                         Flags : DWORD;
                         Date : PSYSTEMTIME;
                         Format : pwidechar;
                         DateBuffer : pwidechar;
                         BufferLen : longint;
                         Calendar : pwidechar
         : BOOL; stdcall; external kernel32;

Steps To Reproduceattempt to compile a program that calls the function.
TagsNo tags attached.
Fixed in Revision
Attached Files


Serge Anvarov

2019-02-20 18:17

reporter   ~0114305

Why not simple constants, but typed?


2019-02-21 00:31

reporter   ~0114315

If I recall correctly, in C they are not typed/static. I used typed constants to ensure FPC would use them the same way they are used in C. I want to avoid having to typecast the constant value in Delphi/FPC because there are occasions when it doesn't work as expected. For instance, passing pchar(' ') as a parameter to something close to guarantees an exception because what's passed is the value $20 as a pointer. On the other hand, passing pchar('a longer string') causes the address of that character sequence to be passed.

If the string is short enough, the typecast considers the value of the string a pointer. If the string is long enough, it passes the address of the string (as it should.) Both Delphi and FPC do that.

Just playing it safe.

Serge Anvarov

2019-02-21 16:37

reporter   ~0114331

If the parameter is defined as a PWideChar, then the compiler:
nil - passed nil
'' (empty, no space) - passed pointer to #0
' ' (one space!) - passed pointer to ' ' (string with space)
'other' - passed pointer to 'other'

Typed const are like global variables - compiler needs to allocate space for them.


2019-02-21 23:56

reporter   ~0114343

"Typed const are like global variables - compiler needs to allocate space for them."

You're right, I know that. From what you posted above, it seems you are getting the desired behavior. I just want to warn you that, there are times that passing pchar(' ') or some other short string causes Delphi (not completely sure about FPC) to pass the _value_ of the string instead of a pointer to it. I've run into that problem enough times (with Delphi) that I got into the habit of declaring constant strings as typed variables.

It is a particularly common problem when using SendMessage. Try sending a message to a listbox, like this, SendMessage(ListboxWnd, LB_ADDSTRING, 0, ptruint(pchar(' ')); (common to add a blank line to a listbox), Delphi sends $20 to the called procedure instead of the address of the space being passed.

I've learned the hard way not to trust what the compiler passes when typecasting a short character/string constant to pchar (I carry that mistrust when using pwidechar - which I almost never use.)

I just checked again, Delphi (v2.0, I haven't tested it with later versions) passes $20 instead of the address of a space, which results in an exception. FPC v3.0.4 passes the address (which is what should be passed) but, honestly, I don't trust either compiler to handle character constants properly.


2019-04-24 05:38

reporter   ~0115757

This comment is just to make this ticket come back to the top in case it has been forgotten.

Additionally, Serge is right, with FPC the constants need _not_ be declared as typed constants. On the other hand, with Delphi, the call may not work as expected if they aren't typed constants.

Issue History

Date Modified Username Field Change
2019-02-19 21:18 440bx New Issue
2019-02-20 18:17 Serge Anvarov Note Added: 0114305
2019-02-21 00:31 440bx Note Added: 0114315
2019-02-21 16:37 Serge Anvarov Note Added: 0114331
2019-02-21 23:56 440bx Note Added: 0114343
2019-04-24 05:38 440bx Note Added: 0115757
2020-03-12 11:39 Marco van de Voort Assigned To => Marco van de Voort
2020-03-12 11:39 Marco van de Voort Status new => assigned