Thanks GCC for warning

[badidea]

I had this code. With 32-bit fbc (via GAS) it compiles without any warning.

Code: Select all

type hex_cube
	dim as integer x 'pointing right/up
	dim as integer y 'pointing left/up
	dim as integer z 'pointing down
end type

type hex_offset
	dim as integer row_, col_
end type

function hex_oddr_to_cube(ho as hex_offset) as hex_cube
	dim as integer x = ho.col_ - (ho.row_ - (ho.row_ and 1)) \ 2
	dim as integer y = ho.row_
	dim as integer z = -(x + z)
	return type<hex_cube>(x, y, z)
end function

With 64-bit fbc (via GCC) I get the warning:

Code: Select all

fbc64 -w all "test.bas" (in directory: /home/badidea/Desktop)
test.c: In function ‘HEX_ODDR_TO_CUBE’:
test.c:36:14: warning: ‘Z$1’ is used uninitialized in this function [-Wuninitialized]
  Z$1 = -(X$1 + Z$1);
         ~~~~~^~~~~~
Compilation finished successfully.

And indeed the warning is a good one, that is a bug in my code.
Are there no 'uninitialized variable checks' possible with FreeBASIC itself?

[Xusinboy Bekchanov]

And indeed the warning is a good one, that is a bug in my code.
Are there no 'uninitialized variable checks' possible with FreeBASIC itself?

I think FreeBasic initializes the variables itself, just not in this case (maybe for speed).

[fxm]

As the declaration 'Dim As Integer I = 1 + I' has an initializer ('='), the allocated memory for 'I' is not cleared first, in order to optimize execution time.
Therefore, this memory value is added to '1', and an unexpected value (not '1') results.

[jj2007]

As the declaration 'Dim As Integer I = 1 + I' has an initializer ('='), the allocated memory for 'I' is not cleared first, in order to optimize execution time.

IMHO FB must zero "i". The coder says explicitly "add 1 to my variable". Adding 1 to a random variable in a Dim statement makes no sense at all.

[fxm]

Rather, it is the user line that makes no sense.

[counting_pine]

FB shouldn't allow z to be used in an expression until after the Dim has finished initialising it.
The problem is that the 'z' variable is visible to the compiler as soon as it is parsed, but isn't in a valid state until it's initialised.
I remember trying to look into this a while back, but I couldn't work out a good way to "hide" the variable between declaring and initialising.

Note, it's a worse problem for things like strings.

[jj2007]

Rather, it is the user line that makes no sense.

Agreed. Which is usually a good occasion for the compiler to shout at the user, i.e. to throw an error message.

Btw clearing variables by default might be the best option. Zeroing a dozen local variables costs micro- or nanoseconds. There are rare occasions where it would impact performance, namely with subs+functions that do little (i.e. have one or two fast instructions, then return) but with huge local buffers. That is non-optimal programming anyway (such stuff should be inlined), but if somebody insists that clearing the locals is an issue, an option NoClear for the current Sub or Function would be a decent solution.

[fxm]

'Dim As Integer I = Any' does the job.

[jj2007]

'Dim As Integer I = Any' does the job.

I would be mad if I had to add =any to all my variables. GfaBasic zeroed them by default, what about QB? This is Assembly btw, the ClearLocals does the job:

Code: Select all

WndProc proc hWin, uMsg, wParam, lParam
LOCAL pt:POINT, rc:RECT, gte:GETTEXTEX
LOCAL SelChg, NoWndProc, chrg:CHARRANGE
LOCAL hdcSource, hdcMemory, hBitmapOld
LOCAL needsShowMenus:BYTE
LOCAL LocBuffer[2*MAX_PATH+2]:BYTE
ClearLocals

[fxm]

GfaBasic zeroed them by default

FB too : 'Dim As Integer I'

[jj2007]

The GfaBasic interpreter always clears the local variables; therefore no warning with Local I%=I%+1. The compiler has a global option "Clear Locals".

In any case the best option would be to throw an error for Dim i=i+1.