#anyopaque ptrCast changing buffer contents

1 messages · Page 1 of 1 (latest)

urban trail
#

I have this code

 var b = JSFunctionBytecode {
    .func_kind = fd.func_kind,
    .byte_code_buf = fd.byte_code.buf,
    .byte_code_len = fd.byte_code.size,
    .stack_size = 0,
  };
 return JS_MKPTR(JS_TAGS.JS_TAG_BYTECODE, &b);
``` where

fn JS_MKPTR(tag: JS_TAGS, p: *JSFunctionBytecode) JSValue {
return JSValue {
.tag = tag,
.u = JSValueUnion {
.ptr = @ptrCast(*anyopaque, p)
}
};
}

And if I print the contents at that `byte_code_buf` after the cast, it is much longer and has very different data than it originally did.  Does this have something to do with the way that I'm casting it?
halcyon fossil
#

It might be pointer aligment

urban trail
#

So I think that when it gets cast as anyopaque... the compiler stops keeping track of the size of the data?

#

So when I go to access the data later...

#

I probably need to include the size somehow when I dereference?

halcyon fossil
#

I mean pointers have the same size

#

they can difer in aligment iirc

urban trail
#

I'm using alignCast to try and align properly when I go to read out the data

# 
fn JS_VALUE_GET_OBJ(v: JSValue) *JSObject {
    std.debug.print("THE INPUT V \n{}\n", .{v.u.ptr});
    // return @ptrCast(*JSObject, @alignCast(@alignOf(JSObject), JS_VALUE_GET_PTR(v)));
    return &JSObject {
      .u = .{
        .func = .{
          .function_bytecode = @ptrCast(*JSFunctionBytecode, @alignCast(@alignOf(JSFunctionBytecode), JS_VALUE_GET_PTR(v)))
          // .function_bytecode = JSFunctionBytecode {
          //   .func_kind = v.u.
          // }
        }
      }
    };
}```
halcyon fossil
#
  • is a pointer, so that's have a size
#

anyopaque itself has no know size

urban trail
#

feeling like syntax highlighting would be very nice right now

halcyon fossil
#

what I don't remember is the aligment of anyopaque

#

alignCast do not align, but is telling the compiler that you know is aligned

#

std.mem.alignBackwards and std.mem.alignFowards do align

urban trail
#

hmm

#

changed the code a bit to find the alignment of anyopaque

# 
./src/main.zig:449:11: error: cast increases pointer alignment
  var b = @ptrCast(*JSFunctionBytecode , JS_VALUE_GET_PTR(bfunc));
          ^
./src/main.zig:449:58: note: '*anyopaque' has alignment 1
  var b = @ptrCast(*JSFunctionBytecode , JS_VALUE_GET_PTR(bfunc));
                                                         ^
./src/main.zig:449:20: note: '*JSFunctionBytecode' has alignment 8
  var b = @ptrCast(*JSFunctionBytecode , JS_VALUE_GET_PTR(bfunc));
                   ^
 /Users/interpretations/projects/quixote$
halcyon fossil
#

to make sure the pointer is aligned as promised

#

is a promise

#

A pinky promise

#

"I for sure have this aligned"

#

which I mean, if it's not valid, it will scream at you

#

so that's that

urban trail
#

well i got it so that when I read the data, it's at least the same size as what was originally written

# 
JSFunctionBytecode{ .func_kind = 0, .byte_code_buf = { 1, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170, 170 }, .byte_code_len = 24, .stack_size = 0 }
THE GOTTEN 
struct:96:11{ .function_bytecode = JSFunctionBytecode{ .func_kind = 0, .byte_code_buf = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 240, 101, 23, 109, 1, 0, 0, 0 }, .byte_code_len = 0, .stack_size = 99 } }
#

Now just need to figure out why the data itself is different

halcyon fossil
#

Time to step by step seeing the changes in that variable

#

via lldb or gdb

urban trail
#

think i have to use lldb since I'm on M1... i've only used it once a long time ago

urban trail
#

Do you know what the equivalent is of -g for clang in zig so that lldb has access to debug symbols?

halcyon fossil
#

it's default in debug mode

#

debug symbols are just there

#

lol