FreeBASIC 1.07 Release Discussion

For other topics related to the FreeBASIC project or its community.
coderJeff
Site Admin
Posts: 3158
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.07 Release Discussion

Postby coderJeff » Oct 01, 2019 22:08

MrSwiss wrote:Instead of making new release packages (definitely to much work).


Sorry, I may have given wrong information somewhere, I've lost track...

The "flags" field is only available in fbc/master (currently version 1.08). The 1.07.1 does not have a flags field available. If you edit your post to remove the flags field and the FBARRAY_FLAGS_* constants, then it should be OK for 1.07.1. Sorry for any misinformation.
Provoni
Posts: 347
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: FreeBASIC 1.07 Release Discussion

Postby Provoni » Oct 03, 2019 6:07

@coderJeff,

About the packages with different GCC versions. I see that you still default to GCC 5.2.0. Why is that? I am not sure what GCC my project needs. While it seems that higher may be better I prefer my project to be save. Won't it be a hassle to compile all these different packages every time?

Thanks for 1.07.1!
coderJeff
Site Admin
Posts: 3158
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.07 Release Discussion

Postby coderJeff » Oct 06, 2019 15:52

Provoni wrote:About the packages with different GCC versions. I see that you still default to GCC 5.2.0. Why is that? I am not sure what GCC my project needs. While it seems that higher may be better I prefer my project to be save. Won't it be a hassle to compile all these different packages every time?


Default is still gcc-5.2.0 for fbc-1.07.1, correct; same as fbc-1.07.0 and several earlier versions of fbc. Intent is to provide a few new options for gcc version. And with the efforts from srvaldez, deltatho, and PaulSquires, they are providing additional options for gcc version as well. For now keeping the reasonably stable and well known base of gcc-5.2.0, and my hope is that we can select and move to a newer gcc version for the 1.08.0 release.

If you don't know or don't care about gcc version, then sticking with default gcc-5.2.0 is fine. When we move to a new default version, then I would recommend that one. True, it is a bit of a hassle to package for so many tool chains. The benefit though is that we are checking that fbc works with so many tool chains.
Provoni
Posts: 347
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: FreeBASIC 1.07 Release Discussion

Postby Provoni » Oct 08, 2019 15:47

Great stuff coderJeff.
robert
Posts: 14
Joined: Aug 06, 2019 18:45

Re: FreeBASIC 1.07 Release Discussion

Postby robert » Oct 09, 2019 16:24

An unbelievably flawless, absolutely perfect install of FreeBASIC-1.07.1-ubuntu-18.04-x86_64.tar.xz on EasyOS Buster 2.1.6 with the corresponding devx installed.

EasyOS Buster is a Debian based Linux by Barry Kauler, the primary developer of the PuppyLinux OS. For details see

http://bkhome.org/news/201910/easyos-bu ... eased.html
Xusinboy Bekchanov
Posts: 112
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.07 Release Discussion

Postby Xusinboy Bekchanov » Nov 10, 2019 11:06

Hello, in version 1.07.1, I can’t read the file on a Unicode string, on ANSI string is read:

Code: Select all

If Open(FileName For Input Encoding "utf-8" As #3) = 0 Then
   Dim As WString Ptr buff
   Dim buffAnsi As String
   WReallocate buff, LOF(3)
   Do Until EOF(3)
      Line Input #3, buffAnsi ' *buff
      ?buffAnsi
   Loop
End If
Xusinboy Bekchanov
Posts: 112
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.07 Release Discussion

Postby Xusinboy Bekchanov » Nov 10, 2019 11:18

1.07.0 too.
dodicat
Posts: 6081
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC 1.07 Release Discussion

Postby dodicat » Nov 10, 2019 12:20

according to the help file:
The encoding to be used when reading or writing text, can be one of:
Encoding "ascii" (ASCII encoding is used, default)
Encoding "utf8" (8-bit Unicode encoding is used)
Encoding "utf16" (16-bit Unicode encoding is used)
Encoding "utf32" (32-bit Unicode encoding is used)

Is "utf-8" a valid string?
Xusinboy Bekchanov
Posts: 112
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.07 Release Discussion

Postby Xusinboy Bekchanov » Nov 10, 2019 12:30

Changed to "utf8". Still not working. But 1.06.0 works
dodicat
Posts: 6081
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC 1.07 Release Discussion

Postby dodicat » Nov 10, 2019 14:10

Where does WReallocate come from?
Tried windows.bi, crt.bi.
. . .
Variable not declared, WReallocate . . .
. . .
Xusinboy Bekchanov
Posts: 112
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.07 Release Discussion

Postby Xusinboy Bekchanov » Nov 10, 2019 14:17

This is your own procedure:

Code: Select all

Sub WReAllocate(ByRef subject As WString Ptr, lLen As Integer)
   subject = Cast(WString Ptr, Reallocate(subject, (lLen + 1) * SizeOf(WString)))
End Sub
coderJeff
Site Admin
Posts: 3158
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.07 Release Discussion

Postby coderJeff » Nov 11, 2019 22:08

Thanks Xusinboy.
- file must have the UTF-8 BOM or OPEN will fail
- encoding "utf8" and "utf-8" specifiers are both valid, the manual doesn't mention that.

The change from 1.06 to 1.07 is due to:
changelog.txt wrote:- github #145: WSTRING concat and assign buffer (&=) overrun


I didn't notice at the time it affected LINE INPUT for WSTRING. Internally, LINE INPUT uses wstring concat and assign to read the input from the file.

fbc and fb run-time lib have no concept of variable length wstrings. fbc tries to know the max buffer length from the variable type, for example 'dim s as WSTRING * N' and passes that to the max number of characters to run-time library functions to limit the buffer length. There were some places in the run-time lib where the maximum characters were unknown, as in the case of passing a wstring ptr buffer, in which case the maximum chars were ignored, leading to a possible buffer overrun.

The work around is as follows:

Code: Select all

extern "rtlib"
   declare function LineInputWstr alias "fb_FileLineInputWstr"_
      ( _
         byval filenumber as long, _
         byval dst as wstring ptr, _
         byval maxchars as integer _
      ) as long
end extern

If Open("file.txt" For Input Encoding "utf-8" As #3) = 0 Then
   Dim As WString Ptr buff
   dim buffAnsi as string
   buff = reallocate( buff, (lof(3) + 1) * sizeof(wstring) )
   Do Until EOF(3)
      LineInputWstr 3, buff, lof(3)
      buffAnsi = *buff
      print buffAnsi
      print *buff
   Loop
   deallocate buff
else
   print "error"
End If


If the file contains many many lines, allocating a buffer of LOF(3) is probably too much. Better will be when fb supports var-len wstring internally.
Xusinboy Bekchanov
Posts: 112
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.07 Release Discussion

Postby Xusinboy Bekchanov » Nov 12, 2019 18:44

This can be fixed in version 1.07 or 1.07.2? I want to use basic-like syntax.
coderJeff
Site Admin
Posts: 3158
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.07 Release Discussion

Postby coderJeff » Nov 30, 2019 13:27

It's not really on my mind to release another 1.07.x, so the safe answer for me is no. The root issue is the potential buffer overflow which I do not intend revert, but we also have changed behavior. I feel like it is combination bug/feature request. Just so it's not forgotten, I have added it as bug ticket #916 line input #h, wstring requires length parameter. Likely could be fixed or have new syntax in 1.08 release.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest