Feed aggregator

Weird result from LEN() on instance of an UDT with operator CAST(), when fbc version is 1.00.0

fbc bugs - Tue, 10/28/2014 - 07:26

Simple UDT:

Type UDT Dim As Zstring PTR pz End Type Dim As UDT u u.pz = Callocate(10) *u.pz = "FreeBASIC" Print (*u.pz)[0] Print Print Len(*u.pz) Print Sizeof(*u.pz) Print Print Len(u) Print Sizeof(u) Print Sleep Deallocate u.pz

Execution output when compiling with fbc version 0.91.0 => OK

70 9 1 4 4

Execution output when compiling with fbc version 1.00.0 => OK

70 9 1 4 4

But now a little more complex UDT (with operator CAST()):

Type UDT Declare Operator Cast () Byref As Zstring Dim As Zstring PTR pz End Type Operator UDT.Cast () Byref As Zstring Return *This.pz End Operator Dim As UDT u u.pz = Callocate(10) *u.pz = "FreeBASIC" Print (*u.pz)[0] Print Print Len(*u.pz) Print Sizeof(*u.pz) Print Print Len(u) Print Sizeof(u) Print Sleep Deallocate u.pz

Execution output when compiling with fbc version 0.91.0 => OK

70 9 1 4 4

Execution output when compiling with fbc version 1.00.0 => NOK

70 9 1 70 4

With fbc version 1.00.0:
- It seems that 'Len(u)' returns '(*u.pz)[0]'!!!
- Is it linked with the addition of LEN() as overloadable operator?

Other remarks:
- For this second example, 'Print u' induces the compiler error 'error 24: Invalid data types' with fbc version 0.91.0, while that works with fbc version 1.00.0 by printing well 'FreeBASIC'.
- Obviously by defining in addition an overload operator LEN(), this works!

Referring to forum at post:
http://www.freebasic.net/forum/viewtopic.php?p=202139#p202139
and the followings.

#742 x86_64: hardcoded-library-path

fbc bugs - Mon, 10/27/2014 - 14:46

I don't see problem. For RPM distros for spec file:
libdir=%{_libdir}
For 32bit it will be "libdir=/usr/lib", for 64bit it will be "libdir=/usr/lib64" automaticly.
Debian has the same macroses.

#742 x86_64: hardcoded-library-path

fbc bugs - Mon, 10/27/2014 - 13:25

I'm not sure...

A libdir=... config option could tell fbc to use lib64/freebasic/ instead of lib/freebasic/ for everything, but then the problem is not really solved, since now the 32bit libs (for cross-compiling from x86_64 to x86) are also under lib64. Same problem, just reversed.

So then something like lib32dir=... and lib64dir=...? But then what about the cross-compiling libs for ARM or other architectures? Are you going to put them into lib/freebasic/ in the cross-compiler toolchain sysroot or Debian's multiarch directories?

From the looks of it, we'd need one libdir config option for each supported target. I haven't tried that yet but it sounds ugly.

fbc already uses a model similar to multiarch for its own internal libs (multiple targets/architectures supported at the same time), and uses gcc -print-file-name=... to find the rest... it works well and is the same on every Linux system. I don't really want to make it more complicated than that. So I'm worrying not just about the libs for native compilation, but also all kinds of cross-compiling.

fb.bas: Remove FB_TARGETOPT_UNDERSCORE and add env.underscoreprefix instead

fbc commits - Fri, 10/24/2014 - 12:36

fb.bas: Remove FB_TARGETOPT_UNDERSCORE and add env.underscoreprefix instead
View Changes

Don't add leading underscores to ASM symbols on Win64 and Cygwin 64bit

fbc commits - Fri, 10/24/2014 - 12:36

Don't add leading underscores to ASM symbols on Win64 and Cygwin 64bit
View Changes

examples: Make libpng example sleep when showing error message on SCREEN

fbc commits - Fri, 10/24/2014 - 10:38

examples: Make libpng example sleep when showing error message on SCREEN
View Changes

rtl-macro: Refactor macro adding code to allow macros to be filtered

fbc commits - Fri, 10/24/2014 - 10:38

rtl-macro: Refactor macro adding code to allow macros to be filtered
View Changes

Fix Hiword() for 64bit

fbc commits - Fri, 10/24/2014 - 10:38

Fix Hiword() for 64bit
View Changes

tests: Add test case for lobyte/hibyte/loword/hiword

fbc commits - Fri, 10/24/2014 - 10:38

tests: Add test case for lobyte/hibyte/loword/hiword
View Changes

KeyPgHibyte

wiki changes - Fri, 10/24/2014 - 06:39
2014-10-24 08:39:56 by DkLwikki - Make similar to KeyPgHiword

KeyPgLoByte

wiki changes - Fri, 10/24/2014 - 06:39
2014-10-24 08:39:45 by DkLwikki - Make similar to KeyPgHiword

KeyPgHiword

wiki changes - Fri, 10/24/2014 - 06:39
2014-10-24 08:39:17 by DkLwikki - Update for 64bit

KeyPgLoWord

wiki changes - Fri, 10/24/2014 - 06:38
2014-10-24 08:38:49 by DkLwikki - Make similar to KeyPgHiword

KeyPgWstring

wiki changes - Fri, 10/24/2014 - 01:37
2014-10-24 03:37:00 by FxMwikki - Clarification

#687 DRAW doesn't remember subpixel positions

fbc bugs - Wed, 10/22/2014 - 13:23
  • status: closed --> open

#687 DRAW doesn't remember subpixel positions

fbc bugs - Wed, 10/22/2014 - 13:23

It looks like the fix introduced a regression (or exposed another issue):

http://www.freebasic.net/forum/viewtopic.php?p=201990#p201990

screen 12 draw "BR20 BD20 G4 H4" line (20, 36) - (16, 40) line (16, 40) - (12, 36) sleep

The DRAW's G and H commands (for drawing diagonal lines down+left and up+left) seem to have rounding issues; they produce "steps" instead of a clean diagonal line of pixels. For comparison, the two LINE commands show what the DRAW should have produced.

It seems to be context-sensitive; for example, with this DRAW, G works ok, but H still has the issue:

screen 12 draw "BM20,20 G4 H4" line (20, 36) - (16, 40) line (16, 40) - (12, 36) sleep

#742 x86_64: hardcoded-library-path

fbc bugs - Mon, 10/20/2014 - 02:28

Will you implement option for build and install? For example, libdir= and the 3rd parameter for install.sh.

#742 x86_64: hardcoded-library-path

fbc bugs - Sun, 10/19/2014 - 20:27

According to file system standard that's true, but it also depends on distro, doesn't it? For example Debian/Ubuntu with multiarch layout uses /usr/lib/x86_64-linux-gnu. Although I think even there /usr/lib64 still exists (and is one of the linker's default search dirs).

FreeBASIC will currently use:
bin/fbc
lib/freebasic/linux-x86
lib/freebasic/linux-x86_64
lib/freebasic/linux-arm
lib/freebasic/linux-aarch64
lib/freebasic/win32
lib/freebasic/win64
which I think is pretty nice.

In a way it's similar to gcc which can also have both 32bit and 64bit libraries in the same directory under a multilib setup. An example from my OpenSUSE x86_64:
/usr/lib64/gcc/x86_64-suse-linux/4.8/
/usr/lib64/gcc/x86_64-suse-linux/4.8/32/
(note the 32bit libs under /usr/lib64)

And it's worth noting that the libraries in lib/freebasic/ are "private" ones, that will be statically linked (currently anyways) (so it's somewhat similar to gcc's libgcc.a).

Honestly I'm not sure what to do yet. I'd prefer keeping it as-is, but if it's really necessary then we can also use lib64 for 64bit stuff:
bin/fbc
lib/freebasic/linux-x86
lib/freebasic/linux-arm
lib/freebasic/win32
lib64/freebasic/linux-x86_64
lib64/freebasic/linux-aarch64
lib64/freebasic/win64

x86_64: hardcoded-library-path

fbc bugs - Sun, 10/19/2014 - 18:56

FreeBasic installed in /usr/lib for x86_64, but it is against policy for packaging x86_64 libraries. You should use /usr/lib64.
hardcoded-library-path in %{_prefix}/lib/freebasic

ProPgProcedurePointers

wiki changes - Sun, 10/19/2014 - 08:46
2014-10-19 10:46:34 by FxMwikki - Added link to a calling example of subroutine pointer

Pages

Subscribe to FreeBASIC Programming Language aggregator