Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2010-11

Some more THandle problems

7 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Sven Barth

Hello together!

While getting SysUtils and Classes to compile for Native NT I've stumbled upon some more spots where Handle=LongInt/LongWord is assumed.

1. In objpas/sysutils/filutilh.inc and its implementation objpas/sysutils/fina.inc the GetFileHandle functions are defined with return type LongInt, but TFileRec.Handle and TFileRec.Handle are defined as THandle (which is - as we know - QWord on Win64).

2. THandleStream has a field FHandle which is defined as Integer. Now this handle is filled either by the constructor which takes an Integer as well or by e.g. TFileStream which gets its handle from FileOpen/FileCreate. Those return a THandle and you might guess what happens if a value >= 2^32 is returned. ^^

3. The handle types for resource streams are defined as PtrUInt while the handle for Native NT is defined as Pointer.
For me locally I've fixed this my casting the handles to the FPResource* types, but I might have reached the point where I should change my handle type from Pointer to PtrUInt, because the pros (no more Ordinal <-> Pointer conflicts) outweigh the cons (no more strict following of the ReactOS headers).

I can provide patches for 1 and 2 in bug reports if you want, but I won't touch the resource related parts mentioned in 3 cause those issues will be fixed when I provide my patch for the Native NT RTL (by changing THandle from Pointer to PtrUInt).

But I've discovered some nice THandle problems while THandle was defined as Pointer. :D

Regards,
Sven

Reply by email

Sergei Gorelkin
to Sven Barth

Sven Barth пишет:

Show quoted text 16 lines
Hello together! While getting SysUtils and Classes to compile for Native NT I've stumbled upon some more spots where Handle=LongInt/LongWord is assumed. 1. In objpas/sysutils/filutilh.inc and its implementation objpas/sysutils/fina.inc the GetFileHandle functions are defined with return type LongInt, but TFileRec.Handle and TFileRec.Handle are defined as THandle (which is - as we know - QWord on Win64). 2. THandleStream has a field FHandle which is defined as Integer. Now this handle is filled either by the constructor which takes an Integer as well or by e.g. TFileStream which gets its handle from FileOpen/FileCreate. Those return a THandle and you might guess what happens if a value >= 2^32 is returned. ^^

1 and 2 fixed in rev. 16383

Show quoted text 8 lines
3. The handle types for resource streams are defined as PtrUInt while the handle for Native NT is defined as Pointer. For me locally I've fixed this my casting the handles to the FPResource* types, but I might have reached the point where I should change my handle type from Pointer to PtrUInt, because the pros (no more Ordinal <-> Pointer conflicts) outweigh the cons (no more strict following of the ReactOS headers).

As long as you use a dedicated type like THandle everywhere, redefining it should be no trouble. The problem is to spot places where such type is intermixed with other types.

Show quoted text 8 lines
I can provide patches for 1 and 2 in bug reports if you want, but I won't touch the resource related parts mentioned in 3 cause those issues will be fixed when I provide my patch for the Native NT RTL (by changing THandle from Pointer to PtrUInt). But I've discovered some nice THandle problems while THandle was defined as Pointer. :D

Indeed, these small bits make up the big picture. Thank you!

Sergei

Reply by email

Marco van de Voort
to Sergei Gorelkin

In our previous episode, Sergei Gorelkin said:

Show quoted text 7 lines
> 2. THandleStream has a field FHandle which is defined as Integer. Now > this handle is filled either by the constructor which takes an Integer > as well or by e.g. TFileStream which gets its handle from > FileOpen/FileCreate. Those return a THandle and you might guess what > happens if a value >= 2^32 is returned. ^^ > 1 and 2 fixed in rev. 16383

Is it wise to recycle thandle for that? Windows has a system where all handles are of the same type, but other systems might not. (and have different handles for e.g. dynloaded shared libs and files).

Reply by email

Sergei Gorelkin
to Marco van de Voort

Marco van de Voort пишет:

Show quoted text 13 lines
In our previous episode, Sergei Gorelkin said: >> 2. THandleStream has a field FHandle which is defined as Integer. Now >> this handle is filled either by the constructor which takes an Integer >> as well or by e.g. TFileStream which gets its handle from >> FileOpen/FileCreate. Those return a THandle and you might guess what >> happens if a value >= 2^32 is returned. ^^ >> > 1 and 2 fixed in rev. 16383 Is it wise to recycle thandle for that? Windows has a system where all handles are of the same type, but other systems might not. (and have different handles for e.g. dynloaded shared libs and files).

I won't say it is very wise, but it is anyway more consistent than using both THandle and Integer/Longint to represent the same handle type (namely file handles) all over the place.

Sergei

Reply by email

Florian Klämpfl
to Marco van de Voort: In our previous episode, Sergei Gorelkin said: Is it wise to recycle thandle for that?…
Marco van de Voort wrote 10 lines
In our previous episode, Sergei Gorelkin said: >> 2. THandleStream has a field FHandle which is defined as Integer. Now >> this handle is filled either by the constructor which takes an Integer >> as well or by e.g. TFileStream which gets its handle from >> FileOpen/FileCreate. Those return a THandle and you might guess what >> happens if a value >= 2^32 is returned. ^^ >> > 1 and 2 fixed in rev. 16383 Is it wise to recycle thandle for that?

At least a lot of code assumes that. See e.g. FileRead and friends.

Windows has a system where all handles are of the same type, but other systems might not.

As soon as we find such a system, we can still introduce a TFileHandle.

Reply by email

Sven Barth
to Sergei Gorelkin: Sven Barth пишет: 1 and 2 fixed in rev. 16383 As long as you use a dedicated type…
Sergei Gorelkin wrote 19 lines
Sven Barth пишет: > Hello together! > > While getting SysUtils and Classes to compile for Native NT I've > stumbled upon some more spots where Handle=LongInt/LongWord is assumed. > > 1. In objpas/sysutils/filutilh.inc and its implementation > objpas/sysutils/fina.inc the GetFileHandle functions are defined with > return type LongInt, but TFileRec.Handle and TFileRec.Handle are > defined as THandle (which is - as we know - QWord on Win64). > > 2. THandleStream has a field FHandle which is defined as Integer. Now > this handle is filled either by the constructor which takes an Integer > as well or by e.g. TFileStream which gets its handle from > FileOpen/FileCreate. Those return a THandle and you might guess what > happens if a value >= 2^32 is returned. ^^ > 1 and 2 fixed in rev. 16383

Thank you. :D

Show quoted text 10 lines
> 3. The handle types for resource streams are defined as PtrUInt while > the handle for Native NT is defined as Pointer. > For me locally I've fixed this my casting the handles to the > FPResource* types, but I might have reached the point where I should > change my handle type from Pointer to PtrUInt, because the pros (no > more Ordinal <-> Pointer conflicts) outweigh the cons (no more strict > following of the ReactOS headers). > As long as you use a dedicated type like THandle everywhere, redefining it should be no trouble.

As I'm either using THandle itself or a type "derived" from it (type HANDLE = THandle), I see no real problem here.

The problem is to spot places where such type is intermixed with other types.

I don't think that I have such spots.

Show quoted text 9 lines
> I can provide patches for 1 and 2 in bug reports if you want, but I > won't touch the resource related parts mentioned in 3 cause those > issues will be fixed when I provide my patch for the Native NT RTL (by > changing THandle from Pointer to PtrUInt). > > But I've discovered some nice THandle problems while THandle was > defined as Pointer. :D > Indeed, these small bits make up the big picture. Thank you!

You're welcome.

Regards,
Sven

Reply by email

Marco van de Voort
to Florian Klämpfl: At least a lot of code assumes that. See e.g. FileRead and friends. As soon as we find…

In our previous episode, Florian Kl?mpfl said:

Show quoted text 6 lines
At least a lot of code assumes that. See e.g. FileRead and friends. > Windows has a system where all > handles are of the same type, but other systems might not. As soon as we find such a system, we can still introduce a TFileHandle.

That was what I wanted to propose yes, since there already was such conflict in the past. (TLibHandle, dynlibs unit)

Reply by email