nikolashn / basque Goto Github PK

The bool type should work as a Boolean value which can take values of 0 or 1, with a size of 1 byte. All non-zero integers when converted to bool are 1, all zeros remain as 0.

For example both of the following programs will output 1 when they should output 0.

i64 x = 0;
i64* ptr = &x;
bool a = 1;
a = [ptr];
write a; "\n";

u8 x = 0;
u8* ptr = &x;
bool a = 1;
a = [ptr];
write a; "\n";

In the following example, when the source code is compiled and run, it will give a segmentation fault. This is because when parsing the second line, the compiler will try to generate code to actually dereference ptr (which is set to 0), rather than just getting the size of the type of [ptr] (a constant known at compile time).

Source code:

i64* ptr = 0;
write $[ptr]; "\n";

Expected output:

8

Actual output: (segmentation fault)

Some day...

Example of code compiled erroneously:

{
    i64 x = 5;
    i64 y = 3;
    i64 a = x * y;
    # Writes "5" instead of "15"
    write a; "\n";
}

Disassembly of the code generated by this example gives the following (comments added by me):

[...]
0000010F  B805000000        mov eax,0x5
00000114  50                push rax
00000115  B803000000        mov eax,0x3
0000011A  50                push rax
0000011B  488B442410        mov rax,[rsp+0x10] ; (incorrect location) x
00000120  488B4C2408        mov rcx,[rsp+0x8] ; (incorrect location) y
00000125  480FAFC1          imul rax,rcx
00000129  50                push rax
0000012A  488B0424          mov rax,[rsp] ; (correct location) a
0000012E  E8CDFEFFFF        call 0x0 ; (internal function) U64ToStr
[...]

They should work the same as in C

For example, compiling main.ba should not give an error about redefining RotL as it currently does, since rotl.ba would not be included the second time compilation reached an include statement. "Included RotL func.\n" should be written out only once.

main.ba

include "rotl.ba";
write RotL(1, 100); "\n";

include "rotatedvars.ba";
write r0; "\n";
write r1; "\n";
write r2; "\n";
write r3; "\n";

rotl.ba

"Included RotL func.\n";
u64 RotL(u64 n, u64 r) {
  return (n << r) | (n >> -r);
}

rotatedvars.ba

include "rotl.ba";
u64 r0 = 0xEEEE_EEEE_EEEE_EEEE;
u64 r1 = RotL(r0, 1);
u64 r2 = RotL(r0, 2);
u64 r3 = RotL(r0, 3);

Seems to have been caused by commit 3d72ca4.

May occur when fileBuf is iterated over multiple times within the while loop, i.e. before the following bounds check:

		while (fileIter < BA_FILE_BUF_SIZE) {

Minimal example:

u64 One(u64 n) {
	if n <= 1u, return 1;
	return One(n-1);
}

One(0); # Compiles with no errors, executes correctly
One(1); # Compiles with no errors, executes correctly
One(2); # Compiles with no errors, execution crashes with segmentation fault

Apparently this only occurs when the func call is on the right hand side of a sub-expression

i64 Mul(i64 x, i64 y) {
	return x * y;
}

write Mul(2, 3) + 1; # Compiles with no issues
write 1 + Mul(2, 3); # Compiler crashes with a segfault
write 1 + (Mul(2, 3)); # Compiles with no issues

For an assignment operation such as,

i64 eutow;
eutow = 6;

When compiled, this gives the following warning, Warning: using uninitialized identifier on line 2:1, which does not make sense for an assignment expression.