Feed aggregator

KeyPgOpPtrIndex

wiki changes - Wed, 11/26/2014 - 09:08
2014-11-26 11:08:56 by CountingPine - Link to ProPgPtrArithmetic

Fix LINE bug added in recent commit.

fbc commits - Mon, 11/24/2014 - 20:44

Fix LINE bug added in recent commit. Clipping case fixed so y1 and y2 are updated, otherwise SET_DIRTY could be passed out-of-bounds values. As it was, y2 could be one too high/low, and y1 was never clipped at all.
View Changes

Forgot this rename in last commit

fbc commits - Mon, 11/24/2014 - 20:21

Forgot this rename in last commit
View Changes

Disallow unknown BMP header sizes, to prevent them being misread.

fbc commits - Mon, 11/24/2014 - 19:21

Disallow unknown BMP header sizes, to prevent them being misread. Allowed sizes are: 12: OS/2 V1 (BITMAPCOREHEADER) 40: BITMAPINFOHEADER 56: BITMAPV3HEADER (undocumented) 108: BITMAPV4HEADER 124: BITMAPV5HEADER
View Changes

Disallow commas/newlines after SPC/TAB

fbc commits - Mon, 11/24/2014 - 19:21

Disallow commas/newlines after SPC/TAB They aren't that useful, and were broken - acting as if a semicolon followed. Now only semicolons are allowed, but that could be reexamined in future releases. There is currently no implementation support for them though, so the code would have to be complicated a little.
View Changes

#751 '=' token not allowed inside parentheses for normal/quirk function calls in N of String * N

fbc bugs - Mon, 11/24/2014 - 16:45

Actually the lexer uses fbGetGtInParensOnly( ) to prevent mis-parsing '>=' in e.g. a as integer<32>=1..
So the above suggestion would require either:
- taking the flag all the way through the expression parser into the lexer
- perhaps to disallow '>=' as well, and allow the integer<> parsing to detect the '>=', take the '>', and push the '=' back as the next token - would that be possible?

Fix: BLOAD was silently misreading bitfields for BMPs with the undocumented BITMAPV3HEADER format (56-byte) headers.

fbc commits - Mon, 11/24/2014 - 02:23

Fix: BLOAD was silently misreading bitfields for BMPs with the undocumented BITMAPV3HEADER format (56-byte) headers. It was treating them the same as the older 24-byte header, which placed the bitfield values after the header (where the colour table is), so was looking for them after the header.
View Changes

#751 '=' token not allowed inside parentheses for normal/quirk function calls in N of String * N

fbc bugs - Mon, 11/24/2014 - 01:31

It also happens with >:

dim i as integer<iif(1 > 0, 32, 32)>

The simplest solution might be to ditch the parser.options flags, and pass down a flags parameter through cExpression() -> cBoolExpression() -> cLogExpression() -> cLogOrExpression() -> cLogAndExpression() -> cRelExpression().

Only compiler warning if function result not explicitly set when the function returns by reference

fbc bugs - Sat, 11/22/2014 - 11:52

For functions returning by value:
When the function result is not explicitly set, the compiler outputs only a warning and returns per default a temporary NULL variable.
=> OK

For functions returning by reference:
When the function result is not explicitly set, the compiler still outputs only a warning and returns (I think) per default a dereferenced NULL pointer that almost always induces a crash (because as the function is defined with return by reference, can be assumed that the return value of the function is used in the calling code).
=> NOK (IMHO)! The compiler should output an error in that specific case:

Function f () Byref As Integer Static As Integer I ' Return I End Function Print @(f()) Print f() Sleep

warning 13(0): Function result was not explicitly set

Output:

0 Aborting due to runtime error 12 ("segmentation violation" signal) in .....

Referring to forum at post:
http://www.freebasic.net/forum/viewtopic.php?p=202444#p202444

#754 Weird error message when a syntax like function result assignment is outside the function body

fbc bugs - Sat, 11/22/2014 - 11:25

Other remark about compiler error message and function with byref return

For functions returning by value:
When the function result is not explicitly set, the compiler outputs only a warning and returns per default a temporary NULL variable.
=> OK

For functions returning by reference:
When the function result is not explicitly set, the compiler still outputs only a warning and returns (I think) per default a dereferenced NULL pointer that almost always induces a crash (because as the function is defined with return by reference, can be assumed that the return value of the function is used in the calling code).
=> NOK (IMHO)! The compiler should output an error in that specific case:

Function f () Byref As Integer Static As Integer I ' Return I End Function Print @(f()) Print f() Sleep

warning 13(0): Function result was not explicitly set

Output:

0 Aborting due to runtime error 12 ("segmentation violation" signal) in .....

Weird error message when a syntax like function result assignment is outside the function body

fbc bugs - Sat, 11/22/2014 - 09:03

When calling a function without arguments, it is advisable to always use empty parentheses, even if parentheses omission is generally accepted by the compiler.

The exception case is when a function returning by reference is used on the left-hand side of an assignment expression.
In that precise case, empty parentheses are mandatory, otherwise a compiler error message is got:

Function f () Byref As Integer Static As Integer I Return I End Function f() = 1 f = 1

error 52: Illegal outside a CONSTRUCTOR, DESTRUCTOR, FUNCTION, OPERATOR, PROPERTY or SUB block, found '=' in 'f = 1'

But the text of this compiler error message is weird compared to the real syntax error!

At least, the terms "CONSTRUCTOR", "DESTRUCTOR" and "SUB" should be ommitted, or the complete sentence changed as proposed previously ( http://www.freebasic.net/forum/viewtopic.php?p=191769#p191769 ) by dkl:
... The error message is a little weird indeed, I think it's supposed to be something like "function/property/operator result assignment outside that function/property/operator". It shouldn't mention constructors/destructors/subs because those don't have function results.

Referring to forum at the synthetic post:
http://www.freebasic.net/forum/viewtopic.php?p=202597#p202597

Assigning a fixed-length string stops to copy at the first appearance of chr(0) and the rest is ignored

fbc bugs - Fri, 11/21/2014 - 20:16

By assigning a fixed-length string, the copying unexpectedly stops at the first appearance of chr(0) in the fixed-length string and the rest is ignored.

Example:

Dim s1 As String * 10, s2 As String * 15, s As String Mid(S1, 1) = "0" Mid(s1, 10) = "9" Print "'"; : Print s1; : Print "'" Print s2 = s1 Print "'"; : Print s2; : Print "'" s = s1 Print "'"; : Print s; : Print "'" Sleep

Output:

'0 9' '0 ' '0'

A workaround is to use the substring function Mid(), even without explicitly pass the substring length as parameter:

Dim s1 As String * 10, s2 As String * 15, s As String Mid(S1, 1) = "0" Mid(s1, 10) = "9" Print "'"; : Print s1; : Print "'" Print s2 = s1 Print "'"; : Print s2; : Print "'" s = s1 Print "'"; : Print s; : Print "'" Print s2 = Mid(s1, 1) Print "'"; : Print s2; : Print "'" s = Mid(s1, 1) Print "'"; : Print s; : Print "'" Sleep

Output:

'0 9' '0 ' '0' '0 9 ' '0 9'

Therefore the first behavior (diect assignment) could probably be improved.

Referring to forum, from the post:
http://www.freebasic.net/forum/viewtopic.php?p=202720#p202720

Cast(Zstring, u) is prohibited even if UDT from 'u' defines the member operator Cast() Byref As Zstring

fbc bugs - Fri, 11/21/2014 - 10:38

'Cast(Zstring, u)' is prohibited in the below example, while 'u' is an instance of an UDT where the corresponding member operator 'Cast() Byref As Zstring' is defined:

Type UDT Declare Operator Cast () Byref As Zstring Dim As Zstring * 7 z = "Hello0" End Type Operator UDT.Cast () Byref As Zstring Return This.z End Operator Dim As UDT u Print u *Cast(Zstring Ptr, @u.z) = "Hello1" Print *Cast(Zstring Ptr, @u.z) 'Cast(Zstring, u) = "Hello2" '' error 28: Expected pointer 'Print Cast(Zstring, u) '' error 28: Expected pointer

At opposite, this seems to be authorized for all other data types, such as 'String' for example:
('Cast(String, u)' autorized if corresponding member operator 'Cast() Byref As String' is defined)

Type UDT Declare Operator Cast () Byref As String Dim As String s = "Hello0" End Type Operator UDT.Cast () Byref As String Return This.s End Operator Dim As UDT u Print u *Cast(String Ptr, @u.s) = "Hello1" Print *Cast(String Ptr, @u.s) Cast(String, u) = "Hello2" Print Cast(String, u)

Remark:
Returning (from function) by reference being mandatory for a Zstring, so I also cited the syntax 'Cast(String, u) = "Hello2' where Cast() is used as lhs term.
But my main question was about the forbidden syntax 'Print Cast(String, u)' where Cast() is conventionally used as rhs term!
(For String, I tested it with the similar syntaxes)

Referring to forum, from the post:
http://www.freebasic.net/forum/viewtopic.php?p=202329#p202329

'=' token not allowed inside parentheses for normal/quirk function calls in N of String * N

fbc bugs - Tue, 11/18/2014 - 13:50

The following currently triggers parser errors, but should probably work:

type a as zstring * iif(1 = 1, 1, 1) type b as zstring * len(str(1 = 1))

I think it's related to the special handling of '=' vs. parentheses in the N expression of STRING * N. Normal parentheses are handled and '=' is allowed inside them, but the parentheses of iif() and other such "functions" are handled differently.

Hang during exit on Windows 10 preview

fbc bugs - Tue, 11/18/2014 - 12:41

FB programs using Screen hang during exit when run on the Windows 10 preview.

http://www.freebasic.net/forum/viewtopic.php?f=6&t=23043

It seems to happen only when using the gfxlib; console programs (including fbc itself) and programs using Win32 API directly work fine.

KeyPgPrint

wiki changes - Mon, 11/17/2014 - 13:02
2014-11-17 15:02:04 by CountingPine

inc/crt/sys/types.bi: Provide off_t on Windows too, like MinGW

fbc commits - Sun, 11/16/2014 - 17:47

inc/crt/sys/types.bi: Provide off_t on Windows too, like MinGW
View Changes

inc: Allegro 4.4.2, algif 1.3, alpng 1.3

fbc commits - Sun, 11/16/2014 - 17:47

inc: Allegro 4.4.2, algif 1.3, alpng 1.3
View Changes

inc: Allegro 5.0.10

fbc commits - Sun, 11/16/2014 - 17:47

inc: Allegro 5.0.10
View Changes

examples: Add Allegro 5 example

fbc commits - Sun, 11/16/2014 - 17:47

examples: Add Allegro 5 example
View Changes

Pages

Subscribe to FreeBASIC Programming Language aggregator