Issues in fbc-1.00

[TJF]

When I compile

Code: Select all

#PRINT TYPEOF(__FB_ARGV__)

on xubuntu14.04-64 bit, I get

$ fbc argv.bas
ZSTRING * 8 PTR PTR

Why * 8?

When I compile the same code with option -r, I get

$ fbc -r argv.bas
argv.bas(16) error 41: Variable not declared, __FB_ARGV__ in '#PRINT TYPEOF(__FB_ARGV__)'
INTEGER

When I try to declare a similar variable with

Code: Select all

DIM AS ZSTRING * 8 PTR PTR test

I get

$ fbc test.bas
test.bas(18) error 4: Duplicated definition, found 'ptr' in 'dim as zstring * 8 ptr ptr test'

???

[dkl]

The #print typeof() output is unfortunately broken at the moment for z/wstring pointers. It includes the pointer size in bytes as the string length even though that does not make sense. I have only a partial fix for it so far...

Either way, zstring * N ptr is not valid FB syntax (at the moment).

If you use -r or -c, you can specify -m <filename-without-extension> to tell the compiler which *.bas file is the main module. __FB_ARGV__ is only available in the main module (in the implicit main() function).

[TJF]

If you use -r or -c, you can specify -m <filename-without-extension> to tell the compiler which *.bas file is the main module.

We always can use option -m. But when we use option -r or -c, we obiously must use option -m as well, now.

Anyway, how can we pass parameters to the init procedure of a library, ie. gdk_init(*int32, ***char);?

[dkl]

Yea, -m must be used at least for the main module if you're using -r or -c. That's not new though - for example, fbc 0.20 already behaved this way.

The following should work (in the main module):

Code: Select all

gtk_init(@__FB_ARGC__, @__FB_ARGV__)

[TJF]

Yea, -m must be used at least for the main module if you're using -r or -c. That's not new though - for example, fbc 0.20 already behaved this way.

Didn't notice that, yet. Thanks for the information.

The following should work (in the main module):

Code: Select all

gtk_init(@__FB_ARGC__, @__FB_ARGV__)

This code I used since years. It still compiles in fbc, but then it results in:

Code: Select all

$ fbc -w all GtkBuilder.bas 
GtkBuilder.c: In function ‘main’:
GtkBuilder.c:90:37: error: lvalue required as unary ‘&’ operand
  gtk_init( &__FB_ARGC__$0, (int8***)&(uint8**)__FB_ARGV__$0 );
                                     ^

Do we realy need a workaround like this, now?

Code: Select all

VAR av = __FB_ARGV__
gtk_init( @__FB_ARGC__, @av )

[dkl]

Hmm, that's a bug in -gen gcc - which is fixed in Git now.

[TJF]

I tried git pull -> nothing found.

[dkl]

Oops, I forgot to push the commits...

[TJF]

Got it now. Fix seems to be OK. Thank you!

[D.J.Peters]

How to solve the warning 4(1): Suspicious pointer assignment with fbc 1.0 ?

Joshy

Code: Select all

function BoxtypeAsString(byval boxtype as integer) as const zstring ptr
  select case as const boxtype
  case FL_NO_BOX : return @"FL_NO_BOX"
  case FL_FLAT_BOX : return @"FL_FLAT_BOX"
  case FL_UP_BOX : return @"FL_UP_BOX"
  case FL_DOWN_BOX : return @"FL_DOWN_BOX"
  case FL_UP_FRAME : return @"FL_UP_FRAME"
  case FL_DOWN_FRAME : return @"FL_DOWN_FRAME"
  case FL_THIN_UP_BOX : return @"FL_THIN_UP_BOX"
  case FL_THIN_DOWN_BOX : return @"FL_THIN_DOWN_BOX"
  case FL_THIN_UP_FRAME : return @"FL_THIN_UP_FRAME"
  case FL_THIN_DOWN_FRAME : return @"FL_THIN_DOWN_FRAME"
  case FL_ENGRAVED_BOX : return @"FL_ENGRAVED_BOX"
  case FL_EMBOSSED_BOX : return @"FL_EMBOSSED_BOX"
  case FL_ENGRAVED_FRAME : return @"FL_ENGRAVED_FRAME"
  case FL_EMBOSSED_FRAME : return @"FL_EMBOSSED_FRAME"
  case FL_BORDER_BOX : return @"FL_BORDER_BOX"
  case FL_SHADOW_BOX : return @"FL_SHADOW_BOX"
  case FL_BORDER_FRAME : return @"FL_BORDER_FRAME"
  case FL_SHADOW_FRAME : return @"FL_SHADOW_FRAME"
  case FL_ROUNDED_BOX : return @"FL_ROUNDED_BOX"
  case FL_RSHADOW_BOX : return @"FL_RSHADOW_BOX"
  case FL_ROUNDED_FRAME : return @"FL_ROUNDED_FRAME"
  case FL_RFLAT_BOX : return @"FL_RFLAT_BOX"
  case FL_OVAL_BOX : return @"FL_OVAL_BOX"
  case FL_OSHADOW_BOX : return @"FL_OSHADOW_BOX"
  case FL_OVAL_FRAME : return @"FL_OVAL_FRAME"
  case FL_OFLAT_BOX : return @"FL_OFLAT_BOX"
  case FL_ROUND_UP_BOX : return @"FL_ROUND_UP_BOX"
  case FL_ROUND_DOWN_BOX : return @"FL_ROUND_DOWN_BOX"
  case FL_DIAMOND_UP_BOX : return @"FL_DIAMOND_UP_BOX"
  case FL_DIAMOND_DOWN_BOX : return @"FL_DIAMOND_DOWN_BOX"
  case FL_PLASTIC_UP_BOX : return @"FL_PLASTIC_UP_BOX"
  case FL_PLASTIC_DOWN_BOX : return @"FL_PLASTIC_DOWN_BOX"
  case FL_PLASTIC_UP_FRAME : return @"FL_PLASTIC_UP_FRAME"
  case FL_PLASTIC_DOWN_FRAME : return @"FL_PLASTIC_DOWN_FRAME"
  case FL_PLASTIC_THIN_UP_BOX : return @"FL_PLASTIC_THIN_UP_BOX"
  case FL_PLASTIC_THIN_DOWN_BOX : return @"FL_PLASTIC_THIN_DOWN_BOX"
  case FL_PLASTIC_ROUND_UP_BOX : return @"FL_PLASTIC_ROUND_UP_BOX"
  case FL_PLASTIC_ROUND_DOWN_BOX : return @"FL_PLASTIC_ROUND_DOWN_BOX"
  case FL_GTK_UP_BOX : return @"FL_GTK_UP_BOX"
  case FL_GTK_DOWN_BOX : return @"FL_GTK_DOWN_BOX"
  case FL_GTK_UP_FRAME : return @"FL_GTK_UP_FRAME"
  case FL_GTK_DOWN_FRAME : return @"FL_GTK_DOWN_FRAME"
  case FL_GTK_THIN_UP_BOX : return @"FL_GTK_THIN_UP_BOX"
  case FL_GTK_THIN_DOWN_BOX : return @"FL_GTK_THIN_DOWN_BOX"
  case FL_GTK_THIN_UP_FRAME : return @"FL_GTK_THIN_UP_FRAME"
  case FL_GTK_THIN_DOWN_FRAME : return @"FL_GTK_THIN_DOWN_FRAME"
  case FL_GTK_ROUND_UP_BOX : return @"FL_GTK_ROUND_UP_BOX"
  case FL_GTK_ROUND_DOWN_BOX : return @"FL_GTK_ROUND_DOWN_BOX"
  case else : return @"UNKNOW_BOX_TYPE"
  end select
end function

[dkl]

I can't reproduce it; the following code compiles fine:

Code: Select all

function BoxtypeAsString(byval boxtype as integer) as const zstring ptr
  select case as const boxtype
  case 0 : return @"FL_NO_BOX"
  case 1 : return @"FL_FLAT_BOX"
  case else : return @"UNKNOW_BOX_TYPE"
  end select
end function

[dkl]

Could you post a small code example that triggers the issue? Then others could test it and see whether they can reproduce it.

By the way, which fbc build are you using? I thought the fbc.exe from 1.00.0 release all had 09-14-2014 build date, not 09-10-2014 (maybe it's from 1.00.0rc1?). (there weren't many changes between 1.00.0rc1 and 1.00.0, so that's probably not the problem... but what else could it be)

[D.J.Peters]

I can't reproduce it; the following code compiles fine

Same here :lol:
I copied the latest version of "ftlk-c.bi" to folder "fltk-ide" and the warnings are gone.
The function BoxtypeAsString() is the same as before
but something was different in the older version of "ftlk-c.bi" and trigers the warning's.

Strange but true.

Joshy

[TJF]

The following should work (in the main module):

Code: Select all

gtk_init(@__FB_ARGC__, @__FB_ARGV__)

Following this topic, where the function is declared like gtk_init(*int, ***char);, and

Code: Select all

#PRINT TYPEOF(__FB_ARGC__)

outputs

LONG

A LONG PTR gets passed as int*. This may cause a massive delay at program init (when something is behind __FB_ARGC__ in memory), or am I wrong?

Isn't is better to make __FB_ARGC__ an INTEGER type (as in C)?

[dkl]

I've just started a wiki page for binding creation issues:
DevBindingCreation

First thing on there: data types. It might already answer your question regarding Integer vs Long. I'm sure I'll have more ideas what to write on this page ;)