Re: [fpc-devel] FPC 3.2.0RC1 released!

2020-05-19 Thread Bart via fpc-devel 
On Tue, May 19, 2020 at 11:44 AM NetSpirit via fpc-devel
 wrote:

> I don't have an account in bug tracker. I post here to get confirmation
> and opinion from other members.
> In hope that one, who can create bug reports, will do this.

Just make one, not so hard.
Unfiled bugreports wiil get forgotten, as Sven pointed out.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.2.0RC1 released!

2020-05-19 Thread Sven Barth via fpc-devel 
NetSpirit via fpc-devel  schrieb am Di.,
19. Mai 2020, 11:44:

> > Please report as a bug.
> >
> >
> > Regards,
> > Sven
> >
>
> I don't have an account in bug tracker. I post here to get confirmation
> and opinion from other members.
> In hope that one, who can create bug reports, will do this.
>

Then it will be forgotten like the resource file bug was.

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.2.0RC1 released!

2020-05-19 Thread Sven Barth via fpc-devel 
NetSpirit via fpc-devel  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

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] FPC 3.2.0RC1 released!

2020-05-19 Thread NetSpirit via fpc-devel 
> 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

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';

===

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.

===

3) This bug still exists:

https://lists.freepascal.org/pipermail/fpc-devel/2016-November/037539.html

===
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}'


===
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.






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel