Bugs

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
dodicat
Posts: 7652
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Bugs

Post by dodicat »

Different results, 32 bits vs. 64 bits.

Code: Select all

'   #cmdline "-gen gcc"
screen 19,32
color rgb(0,0,15),rgb(255,255,255)
cls
print iif(color=rgb(0,0,15),"Yes","No")
sleep 
SARG
Posts: 1567
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Bugs

Post by SARG »

For the comparison on 64bit the value of color is converted in a signed integer, here as it's negative : FFFFFFFFFF00000F but rbg() is used directly that is FF00000F.
Maybe we might consider it's a bug as color returns an ulong.

You need to use culng()

Code: Select all

iif(culng(color)=rgb(0,0,15),"Yes","No") 
coderJeff
Site Admin
Posts: 4017
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Bugs

Post by coderJeff »

Nice find dodicat. I never thought to use 'color' as a function. But it is a function, right there in the docs. lol.

It's a bug, the docs are correct that it should be a ulong, but gfxlib implementation returns a long. Because I didn't test in depth, I will guess that we get weird signed vs unsigned comparison on 64-bit. Bug ticket created: #961 COLOR returns LONG but should be ULONG -- (having a ticket created is helpful to track changes).
dodicat
Posts: 7652
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Bugs

Post by dodicat »

Looking at imageinfo and the size parameter
It seems to over run by 32 bytes.
I have tested various size images and also 32 bit images.
pitch* image height gives a better size.
Check the last 32 bytes (bottom of notepad output)

Code: Select all


screenres 400,300
dim as any ptr i=imagecreate(100,100,2)
dim as ubyte ptr pi
dim as long x,y,pitch,size
Imageinfo i,x,y,,pitch,pi,size

open "data.txt" for output as #1
for n as long=0 to size
      print #1,n;" ";pi[n]
 next
 close #1
 print size,y*pitch
 shell "notepad data.txt"


kill "data.txt"
 
using size given from imageinfo was crashing when I was experimenting with the pointer.
fxm
Moderator
Posts: 11423
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Bugs

Post by fxm »

'size' is the total allocated memory size for the image, including:
- the image buffer header (32 bytes) from the address 'i',
- the image data itself from the address 'pi' (we can check that 'pi' = 'i' + 32).

in 'fbgfx.bi':

Code: Select all

	'' Image buffer header, new style (incorporates old header)
	''
	type IMAGE field = 1
		union
			old as _OLD_HEADER
			type as ulong
		end union
		bpp as long
		width as ulong
		height as ulong
		pitch as ulong
		_reserved(1 to 12) as ubyte
		
'		'' properties
'		declare property pixels() as ubyte ptr
	end type
dodicat
Posts: 7652
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Bugs

Post by dodicat »

Thanks, the last 32 bytes, although the values are meaningless in my code above are actually a count of the first 32 bytes of the actual image, which are meaningful (header).
All the other bytes are a colour.
I can use the actual image pointer instead, starting at byte 32, for my experiment.
dodicat
Posts: 7652
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Bugs

Post by dodicat »

The line style parameter seems not to work very well on 64 bits fbc.

Code: Select all


screen 20,32

Line(20,20)-(500,600),Rgb(255,255,255),,&b10
sleep 
I want a dotted line all the way as in 32 bit fbc.
fxm
Moderator
Posts: 11423
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Bugs

Post by fxm »

A recent coderJeff's commit (2022-09-18) exists:
gfxlib2: LINE statement computing an incorrect line style pattern
SARG
Posts: 1567
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Bugs

Post by SARG »

This has been reported recently and already fixed by Jeff.

edit : beaten by fxm ;-)
dodicat
Posts: 7652
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Bugs

Post by dodicat »

Thank you.
dodicat
Posts: 7652
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Bugs

Post by dodicat »

I'll put this down as a bug (from thread just for fun, starfield with planets orbiting in tips and tricks.
This just about shows it:

Code: Select all

dim as single x=35879
print cshort(x)
sleep

'-32768 32 bits
'-29657 64 bits 
I would have thought the casting would be the same in both compilers (without looking at any asm code produced)
fxm
Moderator
Posts: 11423
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Bugs

Post by fxm »

Not exactly.
As already signaled in the dedicated thread (edited post: viewtopic.php?p=295188#p295188):
'-32768' only with 'gas' (32-bit),
'-29657' with 'gcc' (32/64-bit) and 'gas64' (64-bit).
fxm
Moderator
Posts: 11423
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Bugs

Post by fxm »

But:

Code: Select all

dim as short y=35879
print y

dim as long z=35879
print cshort(z)

dim as single x=35879
print cshort(x)

sleep

' with gas
' -29657
' -29657
' -32768

' with gcc or gas64
' -29657
' -29657
' -29657
The correct value should be: -29657
fxm
Moderator
Posts: 11423
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Bugs

Post by fxm »

See the CSHORT documentation page:
The Cshort function rounds off the decimal part and returns a 16-bit Short value. The function does not check for an overflow, and results are undefined for values which are less than -32 768 or larger than 32 767.
weird behavior only for gas ?
dodicat
Posts: 7652
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Bugs

Post by dodicat »

Fair enough fxm.
But just using the default back end and running a code snippet on each compiler really should produce the same results IMHO.
After all, the data sizes are the same.
-gen gas differs from -gen gcc and -gen gas64, so we have a strange arrangement.
That is all I am asking, is it a bug?
It did catch deltarho[], myself and yourself out, until you pinpointed the offending sub, after a day or two.
Post Reply