Skip to content

Fix string handling in pushAny - #231

Open
AshAmetrine wants to merge 1 commit into
natecraddock:mainfrom
AshAmetrine:fix/pushany-strings
Open

AshAmetrine wants to merge 1 commit into
natecraddock:mainfrom
AshAmetrine:fix/pushany-strings

Conversation

@AshAmetrine

Copy link
Copy Markdown

Changes:

  • Fixes support for null-terminated many-item pointers ([*:0]const u8)
  • Preserves embedded null bytes in strings
  • Avoids allocating temporary null-terminated copies
  • Updates the pushAny test to cover support for [*:0]const u8 and embedded null bytes in string literals

@robbielyman robbielyman left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these changes are sort of surprising to me!

Comment thread src/lib.zig
std.debug.assert(childinfo.child == u8);
std.debug.assert(childinfo.sentinel() != null);

if (childinfo.sentinel()) |sentinel| {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this code deleted?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This assertion rejected pointers to arrays without a sentinel, such as: *const [2]u8.

Comment thread src/lib.zig
}
_ = lua.pushStringZ(std.mem.span(value));
},
.c => @compileError("C pointer length cannot be determined; pass a slice instead"),

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this here? Lua itself obviously works with C pointers all the time?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quoting the Zig documentation: "The only valid reason for using a C pointer is in auto-generated code from translating C code."
I see no reason why they should be supported. The caller should know the type.

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible that the value comes from another C library. I have recently been doing work using Lua and sqlite and I need to work with C strings occasionally. I think C pointers should be supported

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, you would either know the length or whether it has a null terminator, then you could use either ptr[0..len] or std.mem.span(ptr).

If we supported C pointers with pushAny, it would be making the assumption that it has a null terminator, which results in UB when there isn't one.

Side note: I did not remove support for C pointers in this change. I only changed the error message.

Comment thread src/lib.zig
}

/// Pushes any string type
fn pushAnyString(lua: *Lua, value: anytype) error{OutOfMemory}!void {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there really no error condition?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not since the unnecessary temporary allocation was removed.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants