FreeBASIC 1.07 Release Discussion

[jmgbsas]

I have tweaked the cairo code slightly.
I show the mouse and a mapping to the original screen 1024,768.
Also I tested on 64 bits, OK.

Good!

[badidea]

Bug on fbc 1.07.2 32-bit & 64-bit linux? This 'program' segfaults:

Code: Select all

function BC (rv as string) as string
	BC = rv
end function

This also:

Code: Select all

function BC () as string
   return "x"
end function

Or:

Code: Select all

sub BC
end sub

(program exited with code: 139)

I do not know if this bug is new or present in older versions as well, but tests with 1.04.0 and 1.06.0 on Windows did not give problems.

Replace BC with AC and all is fine. I do not see anything weird in the generated .asm or .c file.

[coderJeff]

Replace BC with AC and all is fine. I do not see anything weird in the generated .asm or .c file.

Same fault / behaviour with fb 1.08.0. I suspect that several versions of fb and *nix/*bsd will do this.

Appears that the termcap library has some very short named global symbols PC, BC, and UP, to name a few.

The fault occurs in fbrtlib's start-up code when initializing the console:
rtlib/unix/hinit.c tries to set BC in the termcap library, but when I inspected the address of BC, it's actually address of "sub BC" defined in the fb module.

Looks like 'BC' used in fb rtlib is linking to "sub BC". Not sure why there's no complaint by the linker - maybe has to do with termcap / ncurses being a shared library?

[coderJeff]

I'm working on a full release for fbc 1.07.3 to hopefully wrap up that branch for good.
Older file links for version 1.07.2 & 1.07.3 the sourceforge files may temporarily not work correctly while the mirrors sync up...

[MrSwiss]

Just interested in: why not calling it 1.07.4, in order to avoid ambiguities?
Reason:
we currently have 1.07.3 on WIN64 already.

[coderJeff]

why not calling it 1.07.4, in order to avoid ambiguities?

Lazy, I guess. It's a bunch of extra steps that I just don't want to do to advance the version number for a one line change to fbc. It adds about 8 or 10 hours to what I need to do right now.

Anyway:
- 1.07.3 wasn't a full release - the other targets weren't built & uploaded
- no formal tag yet for 1.07.3 tag in the git repo.
- not announced as a release on github with file hashes, etc.

The previous files on sourceforge.net are getting renamed to *-1.07.3rc0-* to keep them out of the way. Once the mirrors sync up, I can start uploading the new files.

Finally, I am going to press forward with a 1.08.0 release just to get it out there and hopefully never touch 1.07.x again.

[MrSwiss]

Lazy, I guess. <-> It adds about 8 or 10 hours to what I need to do right now.

Isn't that a contradiction in itself ;-))
I fully understand, that you don't want to waste such considerable chunk of time.

Thanks again, for your efforts.

Finally, I am going to press forward with a 1.08.0 release just to get it out there and hopefully never touch 1.07.x again.

This is really exciting news!!!

[coderJeff]

Most of the files are up:
sourceforge.net/projects/fbc/files/FreeBASIC-1.07.3

I'll probably get the repo tagged and news release done a half day from now.

Couple of new things I'm trying:
- new folder structure on sourceforge.net. - it's annoying having spaces in folder names and moving directories around every release
- trying to reduce the number of files
- mostly standalone alone packages for windows FreeBASIC-1.07-3*.*
- no extra normal (toolchain) packages for Windows, nobody uses them on windows anyway
- no extra .ZIP file formats except for Source & Mingworg & DOS

Let me know if you really think something is missing.
DOS version is still building ... it will be up later.

[deltarho[1859]]

@coderJeff

The link in your last post does not work.

[coderJeff]

Thanks deltarho, forgot a word. Fixed now.

[MrSwiss]

Currently running various tests with: FBC 32/64 ver. 1.07.3 / GCC 8.4 WinLib build:
- so far no problems encountered
used:
- Unions
- Array stuff
- console mode
- graphics mode (FBGFX)
- Export (directive)
not yet done:
- create & use of DLL
Will come back if anything "new" pops up ...

P.S. -O 2 & -O 3 optimisations ...

[srvaldez]

thank you coderjeff tor the hard work, much appreciated
when compiling with fbc-gcc-8.1 or above the following gives a warning

Code: Select all

dim as string dayofweek(1 to 7)={"Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"}

warning: array subscript -1 is below array bounds of 'FBSTRING[7]' {aka 'struct <anonymous>[7]'} [-Warray-bounds]

if you start with lbound of 0 then there are no complaints

Code: Select all

dim as string dayofweek2(0 to 7)={"","Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"}

[MrSwiss]

Same here ... GCC 8.4 WinLib.
Seems to be specific to String-Array (static sized).
Not observed with dynamic Array ... (ReDim, instead of Dim).

Also no problems so far with numeric array's.
(this may however, be related to the fact, that I'm typically using BASE0 arrays)

[coderJeff]

when compiling with fbc-gcc-8.1 or above the following gives a warning

This should only be happening with gcc backend + arrays + optimizing.
Workaround is compile with '-Wc -Wno-array-bhounds' or '-fno-tree-vrp'

You can read more about it here: Will this array subscript warning bite me later?

As MrSwiss notes, looks like is only fixed length string arrays.

[srvaldez]

@coderjeff
thanks for the tip