Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1374468

alternatives to null-terminated byte arrays in syscalls in the future?

Show all headers | View raw

The open syscall looks like this:

SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)

filename is a null terminated byte array. Null termination is one way
to handle lengths of byte arrays, but arguably a better way is to keep
track of the length in a separate field. Many programming languages
use pointer + length instead of null termination for various reasons.

When it's time to make a syscall such as open, software which does not
have a null character at the end of byte arrays are forced to allocate
memory, do a memcpy, insert a null byte, perform the open syscall,
then deallocate the memory.

What are the chances that in the future, Linux will have alternate
syscalls which accept byte array parameters where one can pass the
length of the byte array explicitly instead of using a null byte?

Regards,
Andrew Kelley

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

alternatives to null-terminated byte arrays in syscalls in the future? Andrew Kelley <superjoe30@gmail.com> - 2016-04-08 23:10 +0200
  Re: alternatives to null-terminated byte arrays in syscalls in the future? Denys Vlasenko <vda.linux@googlemail.com> - 2016-04-08 23:20 +0200
    Re: alternatives to null-terminated byte arrays in syscalls in the future? Andrew Kelley <superjoe30@gmail.com> - 2016-04-08 23:30 +0200
  Re: alternatives to null-terminated byte arrays in syscalls in the  future? One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-04-09 14:40 +0200

csiph-web