[fpc-devel] FPC 3.2.0RC1 released!

Sven Barth pascaldragon at googlemail.com
Tue May 19 11:16:52 CEST 2020


NetSpirit via fpc-devel <fpc-devel at lists.freepascal.org> schrieb am Di.,
19. Mai 2020, 10:05:

> > if anyone wants to assign me one of the new bugs to fix that have been
> > raised since the RC was released, I'll be happy to take a look. >
> > Gareth aka. Kit
>
>
> Not special for this RC but some bugs:
>
> ===
> 1) packages\winunits-base\src\wininet.pp
>
> Compilation error in -Mdelphiunicode: bad declaration of overloaded
> functions
> FindFirstUrlCacheEntry()
> FindNextUrlCacheEntry()
> with 'W' versions of arguments
>

Please note that compiling the RTL or packages with different modes than
the default is not considered supported.


> Must be equivalent to such with 'A' arguments.
>
> Line 2593:
> function FindFirstUrlCacheEntry(lpszUrlSearchPattern:LPCWSTR;
> lpFirstCacheEntryInfo:LPINTERNET_CACHE_ENTRY_INFOW; var
> lpcbCacheEntryInfo:LongWord):HANDLE;stdcall;external WININETLIBNAME name
> 'FindFirstUrlCacheEntryW';
>
> Line 2636:
> function FindFirstUrlCacheEntry(lpszUrlSearchPattern:LPCWSTR;
> lpFirstCacheEntryInfo:LPINTERNET_CACHE_ENTRY_INFOW; var
> lpcbCacheEntryInfo:DWORD):HANDLE;stdcall;external WININETLIBNAME name
> 'FindFirstUrlCacheEntryW';
>
> Line 2637:
> function FindNextUrlCacheEntry(hEnumHandle:HANDLE;
> lpNextCacheEntryInfo:LPINTERNET_CACHE_ENTRY_INFOW; var
> lpcbCacheEntryInfo:DWORD):BOOL;stdcall;external WININETLIBNAME name
> 'FindNextUrlCacheEntryW';
>
> Line 2656:
> function FindFirstUrlCacheEntry(lpszUrlSearchPattern:LPCWSTR; var
> lpFirstCacheEntryInfo:INTERNET_CACHE_ENTRY_INFOW;
> lpcbCacheEntryInfo:LPDWORD):HANDLE;stdcall;external WININETLIBNAME name
> 'FindFirstUrlCacheEntryW';
>
> Line 2657:
> function FindNextUrlCacheEntry(hEnumHandle:HANDLE; var
> lpNextCacheEntryInfo:INTERNET_CACHE_ENTRY_INFOW;
> lpcbCacheEntryInfo:LPDWORD):BOOL;stdcall;external WININETLIBNAME name
> 'FindNextUrlCacheEntryW';
>

Please report as a bug.


> 2) rtl\win\wininc\struct.inc
>
> Members 'lData' of NEWCPLINFOA/NEWCPLINFOW have different types. I think
> both must be LONG_PTR.
>
> Member 'code' of NMHDR must have 'Integer' type, becouse constants, used
> here, are signed. This cause wrong comparison results or require explicit
> cast everywhere in user code.
>

Please report as a bug.


> 3) This bug still exists:
>
> https://lists.freepascal.org/pipermail/fpc-devel/2016-November/037539.html
>
>
Did you report this as a bug back then? If not, please do so.


4) packages\pasjpeg\src\jconfig.inc
>
> There is explicit declaration of {$MODE DELPHI}, so 'pasjpeg' is
> incompatible with -Mdelphiunicode.
> Can be '{$ifndef UNICODE}{$MODE DELPHI}{$endif}'
>

Again we don't support compiling the RTL and packages with anything than
the default mode.


> Just question. Why NativeInt / NativeUInt declaration changed to strong
> aliases? To be new Delphi compatible? But this inconvenient in Delphi, and
> so in FPC. Old code become broken.
>

This is compatible with Delphi and is required to allow overloads as
noticed by this bug report that triggered this change:
https://bugs.freepascal.org/view.php?id=29444

If it is inconvenient for you, then use PtrInt/PtrUInt.

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20200519/5b2e26d7/attachment.htm>


More information about the fpc-devel mailing list