Suspicious pointer assignment, how pointers work?

[mrminecrafttnt]

I did not realy understand how pointers work and get the "Suspicious pointer assignment" error?

Code: Select all

dim as integer ptr mem = allocate (len(integer))
if mem = 0 then print "Allocate failed" : sleep : end
dim as integer ptr d = @mem
deallocate (mem)

My question is how to do this without this error?

[fxm]

'd' is a pointer to the integer pointer 'mem'.
So 'd' is naturally an 'integer ptr ptr':

Code: Select all

dim as integer ptr mem = allocate (len(integer))
if mem = 0 then print "Allocate failed" : sleep : end
dim as integer ptr ptr d = @mem
deallocate (mem)

If you absolutely want to force the 'd' type to 'integer ptr' (I do not see the interest here), you must explicitly cast the assigning variable:

Code: Select all

dim as integer ptr mem = allocate (len(integer))
if mem = 0 then print "Allocate failed" : sleep : end
dim as integer ptr d = cast(integer ptr, @mem)
deallocate (mem)

[mrminecrafttnt]

'd' is a pointer to the integer pointer 'mem'.
So 'd' is naturally an 'integer ptr ptr':

Code: Select all

dim as integer ptr mem = allocate (len(integer))
if mem = 0 then print "Allocate failed" : sleep : end
dim as integer ptr ptr d = @mem
deallocate (mem)

If you absolutely want to force the 'd' type to 'integer ptr' (I do not see the interest here), you must explicitly cast the assigning variable:

Code: Select all

dim as integer ptr mem = allocate (len(integer))
if mem = 0 then print "Allocate failed" : sleep : end
dim as integer ptr d = cast(integer ptr, @mem)
deallocate (mem)

Thanks this helps a lot!

Here is an example how to read the mem value from the d pointer

Code: Select all

dim as integer ptr mem = allocate (len(integer))
*mem = 12345
dim as integer ptr ptr t = @mem
print **t
sleep
deallocate(mem)

[fxm]

Perfect example.
Good data typing => dereferencing works well.

[mrminecrafttnt]

My next question is how is this Syntax correct?

Code: Select all

dim as integer ptr mem = allocate (len(integer)*2)
if mem = 0 then print "Allocate failed" : Sleep : end
dim as integer ptr ptr t = @mem
*mem[0]=12345
*mem[1]=54321
print **t[0]
print **t[1]
deallocate(mem)
sleep

[fxm]

It gets complicated:

Code: Select all

dim as integer ptr mem = allocate (len(integer)*2)
if mem = 0 then print "Allocate failed" : Sleep : end
dim as integer ptr ptr t = @mem
mem[0]=12345   '' 'mem[0]' is equivalent to '*(mem + 0)' 
mem[1]=54321   '' 'mem[1]' is equivalent to '*(mem + 1)' 
print (*t)[0]  '' '(*t)[0]' is equivalent to '*(*t + 0)', parentheses are required in '(*t)[0]' because '[]' takes precedence over '*'
print (*t)[1]  '' '(*t)[1]' is equivalent to '*(*t + 1)', parentheses are required in '(*t)[1]' because '[]' takes precedence over '*'
deallocate(mem)
sleep

[mrminecrafttnt]

It gets complicated:

Code: Select all

dim as integer ptr mem = allocate (len(integer)*2)
if mem = 0 then print "Allocate failed" : Sleep : end
dim as integer ptr ptr t = @mem
mem[0]=12345   '' 'mem[0]' is equivalent to '*(mem + 0)' 
mem[1]=54321   '' 'mem[1]' is equivalent to '*(mem + 1)' 
print (*t)[0]  '' '(*t)[0]' is equivalent to '*(*t + 0)', parentheses are required in '(*t)[0]' because '[]' takes precedence over '*'
print (*t)[1]  '' '(*t)[1]' is equivalent to '*(*t + 1)', parentheses are required in '(*t)[1]' because '[]' takes precedence over '*'
deallocate(mem)
sleep

Thats all i need to know, thanks

[Emulog]

All warnings about "suspicious assigment" may be shun with -w 3 option to the fbc.
I always use pointers without explicit casting, that depends on used data, sometimes it needs to be copied as uint64, sometimes as uint16, and all those warnings just take place in compiler report window, meaning no error at all.
Also there is a quite a surprise that integer type on x64 is same as ulongint in FB, thus takes 4 times more space than normal integer of 16 bit, while the fastest ones are usual long 32 bit integers.

[caseih]

32-bit integers are faster? How do you figure? In general data in 64-bit chunks on a 64-bit processor is the most efficient, especially in terms of fetching.

The fact that Integer on FB is 32-bit even on 64-bit is quite a gotcha when interfacing with C api calls. Makes more sense to me to define int (or Integer) as the same size as the processor's registers, but alas we cannot change Integer now.

[dodicat]

Gotcha is a fact.
I hardly see integer<bits> being used in fb, although it is a solution for all occasions.

Code: Select all

#macro bits(n)
scope
Dim As Integer<n> Ptr mem = Allocate (Len(Integer<n>)*2)
If mem = 0 Then Print "Allocate failed" : Sleep : End
Dim As Integer<n> Ptr Ptr t = @mem
dim as uinteger<n> x=-1
t[0][0]= x\2
t[0][1]=Sizeof(Integer<n>)
Print mem[0]
Print mem[1]
Deallocate(mem)
print
end scope
#endmacro


bits(8)
bits(32)
bits(64)
sleep
 

[Emulog]

32-bit integers are faster? How do you figure?

Oh, this is MHO. In terms of alignment and cache misses, uint64 vs uint32 fetch faster, but in terms of data packing into uint64, say two uint 32 to one uint64 and then use high and low dword separately for something, will need shifts, to pack back will need and/or sequences.
It depends. For just math is okay. A lot of various data may be shorter than uint64.
And my tests show that 16 and 8 bit reads are actually slower a bit, because always have subsequent movzx asm opcodes. 16/8 writes even worse.