#PB_Any object result values after PB 6.20

[PBJim]

A year or so ago, when PB 6.00 was superseded by a subsequent version, the resulting 64-bit integer object value for open files, network connections, mutex, semaphores and others, increased from the usual 7 - 8 digits, almost doubling in length.

Since these values form part of the usability of our application, with some of them visible to administrative users, the length of the number became impractical. I know what our options are, but none of them are straightforward and they are unwelcome in some ways, given the usage of the system.

Can I ask, first of all, what exactly does the result refer to — for instance is it a memory location? Is the random pattern that we see, due to the Microsoft linker? (if my recollection is correct, that's the change that was made).

Below shows what we see in PB 6.00 Windows 64-bit at the moment (actual values are shown after the code).

Code: Select all

#MAXLOOP = 10

fpath.s = "E:\Temp\"

Dim flist(#MAXLOOP)

For counter.i = 1 To #MAXLOOP
  flist(counter) = OpenFile(#PB_Any, fpath.s + "file-" + counter, #PB_Ascii)
  Debug flist(counter)
Next

1969312
1973488
1973552
34726064
1981840
34726128
1990128
34726192
1998416
34726256

[Caronte3D]

...what exactly does the result refer to — for instance is it a memory location?...

I think, yes!
If I remember well PB reserve memory for this when #PB_Any is used.

[tored]

What does an administrative user do with these ids? The administrative user cannot really share these with anyone, like over the phone, because they are local to his running instance.

Thus one solution is to remap these numbers with your own Map where you can use any sequence you like as long as unique.

[Fred]

You're playing with fire here, there is absolutely no warranty than these ids will stay in this 7-8 digits range on all 64-bit computers. PB now use the high entropy flags to ensures the app is robust against memory based attacks, but you can still deactivate this for backward compat by putting this code somewhere in your source to disable it:

Code: Select all

Import "/dynamicbase:no"
EndImport

Import "/HIGHENTROPYVA:no"
EndImport

It should not be done in new programs as it's a programming error to store the 64-bit address into a 32-bit variable.

[PBJim]

Thanks for the replies. Yes, we have cross-referenced them in a map as you say @Tored, but it's clunky to see it in code throughout that used to be elegant.

Another solution that's been considered is not using dynamic #PB_Any, but instead generating them as index mode. On this basis, we can just call our own function MyPB_Any() which returns a serialised number, but in fact this is not as elegant as I would like, because PB doesn't pass the indexed number into the resulting variable. So in other words, the below doesn't work because flist(counter) will not contain the file number (it returns arbitrary values). I can fix that obviously, but again, it isn't a drop-in change that preserves the simplicity of the code.

Code: Select all

#MAXLOOP = 10

fpath.s = "E:\Temp\"

Global pb_any.i

Dim flist(#MAXLOOP)

Procedure.i MyPB_Any()
  
  pb_any.i + 1
  ProcedureReturn pb_any.i
  
EndProcedure

  
For counter.i = 1 To #MAXLOOP
  flist(counter) = OpenFile(MyPB_Any(), fpath.s + "file-" + counter, #PB_Ascii)
  Debug flist(counter)
Next

[PBJim]

It should not be done in new programs as it's a programming error to store the 64-bit address into a 32-bit variable.

Thanks for that, it's interesting to know, but yes I agree it's not a good practice here in a serious application.

What is the implication — that over a certain memory capacity, it would need a 64-bit value and therefore not be able to access it?

[Fred]

yes and the result is always a memory corruption/crash

[Caronte3D]

Not elegant either, but...

Code: Select all

#MAXLOOP = 10

fpath.s = "E:\Temp\"

Global pb_any.i

Dim flist(#MAXLOOP)

Procedure.i MyPB_Any()
  
  pb_any.i + 1
  ProcedureReturn pb_any.i
  
EndProcedure

  
For counter.i = 1 To #MAXLOOP
  flist(counter) = MyPB_Any()
  OpenFile(flist(counter), fpath.s + "file-" + counter, #PB_Ascii)
  Debug flist(counter)
Next

[PBJim]

yes and the result is always a memory corruption/crash

Just to clarify, we're not looking to prevent usage of higher memory — if the value returned is high, then that's unavoidable, for sure.

Rather, the problem for us has been that the high memory is chosen by default, even when low memory is available.

[PBJim]

Not elegant either, but...

Code: Select all

  flist(counter) = MyPB_Any()
  OpenFile(flist(counter), fpath.s + "file-" + counter, #PB_Ascii)
  Debug flist(counter) 

Yes, that's the solution I had in mind Caronte, but unfortunately throughout a big lot of code, it's a very substantial and time consuming change.

At the moment, it's just a very elegant few words :

Code: Select all

fileno = OpenFile(#PB_Any, ... 

There is also another disadvantage with indexed mode, as you can't start at a high number, or leave gaps in the numbering. It's consumes memory for unused numbers in the range. If a client disconnects, or a file is closed, for instance, we have to be sure to re-use its number, otherwise it's wasted.

[NicTheQuick]

Why do you need these values in the first place? What is the reason to even look at these numbers or memory locations?
If you allow a user to input a memory location and your program does something with it, then that sounds like a good indicator for crashes and security problems.

[the.weavster]

I don't really understand the use case but...
How about an alternative version of OpenFile() rather than MyPB_Any():

Code: Select all

#MAXLOOP = 10

fpath.s = "E:\Temp\"

Dim flist(#MAXLOOP)

Procedure.i OpenFileEx(Filename$, Flags)
  Static pb_any.i
  If pb_any = 0 : pb_any = 123 : EndIf ; <- change initial index if you want
  
  pb_any + 1
  If OpenFile(pb_any, Filename$, Flags)
    ProcedureReturn pb_any
  Else
    ProcedureReturn pb_any * -1 ; negative number = error
  EndIf
EndProcedure
  
For counter.i = 1 To #MAXLOOP
  flist(counter) = OpenFileEx(fpath.s + "file-" + counter, #PB_Ascii)
  Debug flist(counter)
Next

; search and replace "OpenFile(#PB_Any," with "OpenFileEx("

Does that give you what you want?

[miso]

I don't know the whys, but:

Code: Select all

Procedure.i File_getfirstunusedID()
  Protected id.i = 0
  Repeat
    If Not IsFile(id) : ProcedureReturn id.i : EndIf
    id.i + 1
  ForEver
EndProcedure

Debug File_getfirstunusedID()

[PBJim]

Thanks for the suggestions, they are things that we've considered.

The ideal solution, which Fred's reply doesn't mention, is if we can use one of those mentioned switches to request a low-memory allocation, but NOT prevent it. In those rare cases when memory usage is high and we get the high-memory result, we can just live with it. That was always the case with PB 6.00 anyway — we've never tried to stop the high values, it's just that we never saw them.

But we don't want to force a 64-bit memory address in a 32-bit, which was not asked for. Perhaps Fred can confirm if that is possible. Thanks.

[Fred]

I don't understand your question