Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758914AbcDHVLO (ORCPT ); Fri, 8 Apr 2016 17:11:14 -0400 Received: from mail-qk0-f173.google.com ([209.85.220.173]:33561 "EHLO mail-qk0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750819AbcDHVLN (ORCPT ); Fri, 8 Apr 2016 17:11:13 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Denys Vlasenko Date: Fri, 8 Apr 2016 23:10:52 +0200 Message-ID: Subject: Re: alternatives to null-terminated byte arrays in syscalls in the future? To: Andrew Kelley Cc: Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1085 Lines: 23 On Fri, Apr 8, 2016 at 11:04 PM, Andrew Kelley wrote: > 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. In many cases, it's possible to just add the NUL byte instead. > 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? 0% chances. Amount of PITA to make that happen far outweighs possible benefits.