Integer overflow while trying to patch jumps in a JIT

[indigo wagon]

m_output is a std.ArrayList(u8)

pub const BasicBlock = struct {
    instructions: std.ArrayList(Instruction),
    jump_stack: std.ArrayList(usize),
    offset: usize,
    allocator: std.mem.Allocator,
    index: usize
};

pub const Program = struct {
    blocks: std.ArrayList(*BasicBlock),
    allocator: std.mem.Allocator
};

in his video instead of appending .items.len he appends .size(), from what I know (Write Vector).size() returns m_size which should be the same

If anyone is interested, I can open the repo

and the emits:

    pub inline fn emit8(self: *Assembler, v: u8) !void {
        try self.m_output.append(v);
    }

    pub inline fn emit32(self: *Assembler, v: u32) !void {
        try self.m_output.writer().writeIntLittle(u32, v);
    }```

[high agate]

what's b.offset and j look like in this example

[eager dirge]

probably just going negative with bad arithmatic

[indigo wagon]

j is usize

b.offset also usize

[indigo wagon]

as seen here

[eager dirge]

okay and what's 1-2?

[indigo wagon]

i know what integer overflow is.

I wanna know why it does work in C++

i mean c++ isn't very safe but it did run

[trim hearth]

idk if it's different in c++, but in C, unsigned integer overflow is defined behavior

it just wraps around

but in zig, unsigned overflow is UB

[indigo wagon]

he used auto in the video

hmm

only i128 can do it?

[bold monolith]

which iteration gives off the error?

[indigo wagon]

so it works if i only have two instructions in 2 blocks

1st block:
jmp 2nd block
2nd block:
ret

compiled to

jmp 0x5
ret

if i comment out these instructions

it actually compiles

if i uncomment atleast one of them, it fails

[zinc nexus]

Maybe try debugging to see what is acutally happening? Either with std.debug.print or a debugger.

[indigo wagon]

Block iter: {block iter index}={offset}, Jump iter: {jump iter index} = { jump }

[zinc nexus]

well 100 - 300 is overflow for a usize

[indigo wagon]

yep...

i am confused

this code probably has UB

it's saying block 1 has a jump but...

[bold monolith]

or your math is wrong

[indigo wagon]

oh wait no

it's jumping to 1....

that's why

jump is higher than block offset

[eager dirge]

.

[indigo wagon]

yep

but I wonder why c++ works

i mean

yeah

defined behaviour

but what should I do instead

[eager dirge]

Figure out what’s wrong with the logic. Either using a debugger or print debugging

[indigo wagon]

what do you want me to debug?

[eager dirge]

you've done the job of transcribing someone elses code. Now do the hard work of understanding what the program is supposed to do and what is wrong with your transcription

[zinc nexus]

Maybe start by doing the same printf debugging you've done so far on the C++ version and seeing what is different. These aren't really Zig related questions though.

[indigo wagon]

the first revision of c++ code that was uplaoded was after a couple of episodes

but okay.

[eager dirge]

What do you expect someone trying to help you to do in the current situation?

[indigo wagon]

anything but not say "Oh debug smthn. idk"

i'll just copy the c++ code and debug then

[eager dirge]

bro, there's no longer any zig issues. You haven't even posted your full code. You're asking someone to solve your problem without putting in the effort to solve it yourself

[indigo wagon]

I sent code that is mostly related, and also I said I am willing to provide the entire source code

[indigo wagon]

^

[bold monolith]

I have a feeling that something might be out of sequence.
but it looks exactly like a situation where you need to do just that – debug. It's not a situation that's related to zig at all. You have a bug, so go debug.
But it would be best if next time you trim more whatever you give us. Reduce your problem to the minimum that's required for it to display itself. The less noise, the more help. Most of the time, you'll have caught the bug yourself by that time.