Feed aggregator

#768 View [Screen] doesn't clip to screen properly

fbc bugs - Sat, 01/31/2015 - 12:36
  • Component: compiler --> gfxlib2

View [Screen] doesn't clip to screen properly

fbc bugs - Sat, 01/31/2015 - 12:36

Reported by Mysoft on IRC:

This code example causes buffer overruns during drawing due to the previous View doing clipping incorrectly:

#include once "fbgfx.bi" screenres 320, 240, 8, , fb.GFX_WINDOWED view screen (-20,-20)-(340,260) line(-20,-20)-(340,260),10,bf

It seems like the main cause of the problem is that the clipping code in fb_GfxView() is buggy - it allows context->view_{w|h} to be bigger than __fb_gfx->{w|h}. This can happen at least in case x1/y1 are negative.

Furthermore, in a case like this:

#include once "fbgfx.bi" screenres 320, 240, 32, , fb.GFX_WINDOWED view screen (-5, -5) - (4, 4) line (-500, -500) - (500, 500), rgb(255,0,0), bf line (0, 0) - (4, 4), rgb(0,255,0), bf

drawing is clipped to the screen's 0,0 - 9,9, and drawing is relative to the screen's 0,0, so the viewport seems to be moved instead of clipped. According to Mysoft, this triggers an Illegal Function Call in QB. Negative x1/y1 probably don't make much sense for View... but in FB, fb_GfxView() doesn't have an error return, so we probably only have the choice between doing nothing or clipping.

View [Screen] doesn't clip to screen properly

fbc bugs - Sat, 01/31/2015 - 12:36

Ticket 768 has been modified: View [Screen] doesn't clip to screen properly
Edited By: dkl (dkls)
_component updated: u'compiler' => u'gfxlib2'

KeyPgShared

wiki changes - Fri, 01/30/2015 - 01:32
2015-01-30 03:32:34 by FxMwikki - Reformat

KeyPgShared

wiki changes - Thu, 01/29/2015 - 15:31
2015-01-29 17:31:12 by FxMwikki - Added exception for shared variable initializing

#765 DBL_MAX evaluates to #INF

fbc bugs - Sat, 01/17/2015 - 20:55
  • status: open --> closed
  • Component: compiler --> headers

#765: Fix precision on FLT_MAX / DBL_MAX

fbc commits - Sat, 01/17/2015 - 20:54
765: Fix precision on FLT_MAX / DBL_MAX They were each one digit too short. FLT_MAX was too low and DBL_MAX was overflowing. This possibly happened because FB prints numbers with one too few digits precision, in order to prevent things like 8.1f being printed as 8.1000004.
View Changes

Weird compiler message on assignment error for function return when that is by reference

fbc bugs - Tue, 01/13/2015 - 09:42

A function with Byref return is internally coded using a hidden pointer.
This may explain why some errors of return assignment are highlighted by a warning: "Suspicious pointer assignment".
(this is not always true, even when the equivalent expression of pointer assignment is declared "Suspicious")

Example:

Dim As Integer Ptr pi = @"0" '' warning: Suspicious pointer assignment Function fi () Byref As Integer Return "0" '' warning: Suspicious pointer assignment End Function Dim As String Ptr ps = @"0" '' warning: Suspicious pointer assignment Function fs () Byref As String Return "0" '' error: Invalid data types End Function

Compiler output:
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(1) warning 4(1): Suspicious pointer assignment
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(3) warning 4(1): Suspicious pointer assignment
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(6) warning 4(1): Suspicious pointer assignment
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(8) error 24: Invalid data types in 'Return "0"'
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(9) error 315: Byref function result not set in 'End Function'

On assignment error for function return when that is by reference:
- Could we change this compiler message "Suspicious pointer assignment" that may seem obscure to an inexperienced user?
- Knowing that the internal pointer will generally be dereferenced, it can be risky to send a warning only (and not an error)!

Referring to forum at:
http://www.freebasic.net/forum/viewtopic.php?p=204200#p204200

make bindist: No longer exclude Windows API headers from 64bit packages

fbc commits - Mon, 01/12/2015 - 17:19

make bindist: No longer exclude Windows API headers from 64bit packages
View Changes

inc: New Windows API headers based on MinGW-w64 3.3.0

fbc commits - Mon, 01/12/2015 - 14:33

inc: New Windows API headers based on MinGW-w64 3.3.0
View Changes

winapi examples: Fix AdjustWindowRect() call

fbc commits - Mon, 01/12/2015 - 14:33

winapi examples: Fix AdjustWindowRect() call
View Changes

winapi examples: Fix BrowseCallbackProc() to work on 64bit

fbc commits - Mon, 01/12/2015 - 14:33

winapi examples: Fix BrowseCallbackProc() to work on 64bit
View Changes

winapi examples: #include windows.bi before wininet.bi

fbc commits - Mon, 01/12/2015 - 14:33

winapi examples: #include windows.bi before wininet.bi
View Changes

#765 DBL_MAX evaluates to #INF

fbc bugs - Mon, 01/12/2015 - 08:42

...2316 is too high (I think 2^1024 is ...23159).
...2315 is too low (I think there is also ...23155, ...23153,...)
We need the extra digit's precision, like in C.

The compiler doesn't accept unicode in the program file name

fbc bugs - Sun, 01/11/2015 - 19:24

The compiler seems to not handle the unicode BAS filename. Like ALREDY SQUARE WIÐ BETT QUOTIETNS.BAS – the results, which are being instructed to go to a .TXT with “>” command, output the Ð as a question. The compiler thinks it fulfilled the first level. And then it looks for the .ASM, but can't find it. This TXT too, appears as 1-byte text, not unicode. (The system is .XP with all NTFS.)

DBL_MAX evaluates to #INF

fbc bugs - Sun, 01/11/2015 - 01:02

Ticket 765 has been modified: DBL_MAX evaluates to #INF
Edited By: Matthew (counting_pine)
Status updated: u'open' => u'closed'
_component updated: u'compiler' => u'headers'

DBL_MAX evaluates to #INF

fbc bugs - Sun, 01/11/2015 - 01:02

DBL_MAX evaluates to #INF

' in limits.bi #define DBL_MAX (1.797693134862316e+308)
' should be #define DBL_MAX (1.797693134862315e+308)
' in c it's 1.7976931348623157e+308

#742 x86_64: hardcoded-library-path

fbc bugs - Fri, 01/09/2015 - 16:13

I'm not sure whether a global config file would be a good idea though - there can be multiple fbc installs with their own libdirs each. If they all read the same /etc/fbc.cfg that would be a problem.

Ideally the config file would be specific to each fbc - i.e. in the lib/freebasic/ directory belong to that fbc (much like ldscripts). And I think at that point it comes down to symlinks.

Update fbc help output

fbc commits - Fri, 01/09/2015 - 14:18

Update fbc help output
View Changes

Pages

Subscribe to FreeBASIC Programming Language aggregator