Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117048 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 19842 invoked from network); 16 Feb 2022 11:07:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Feb 2022 11:07:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AFABE1804D0 for ; Wed, 16 Feb 2022 04:25:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 16 Feb 2022 04:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1645014303; bh=ebw94f4y5muufZgRBCFpgKDgK4gaCG6vng8LtcQ6ai0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=KAkxellFf4dEKjh8CIBEm0PjpyiiZJAFBp4ZLJiMBVIzrrdxFc00fq88G6fIJpgo8 j70Zm2EX/cbsGEcS7RceUVCsdqeHSyBujPk9Afbh6k8OLsIvqW8fN526lLEWMIjHMe hHAIVdJmLQVj4zE2zbYT3/tU67I/r/cBQzJB6YspcPIXYvy2L5hkf/HOtJyOCvHwgh /L9vrzflKLwjfCjdnBTBjSu2T5aFdWM5yxVULMzJezx1Sbp64rOILMmEJJEBeGs8Cv tRLVxRac8o/z1KWLdzStQeM6zMR0BQ9SZzZwhOCqHXFLJkHTRa3R5RCyj6qcHn2rGi GyT1dsm6ZzT0w== Message-ID: Date: Wed, 16 Feb 2022 13:25:02 +0100 MIME-Version: 1.0 Content-Language: en-US To: Go Kudo Cc: internals@lists.php.net References: <41a1b458-4941-f34e-f1b4-e25b3298b80a@bastelstu.be> <553ba7ca-3821-c2d9-f88f-b216013a887b@bastelstu.be> <2c667812-88c8-0b7b-3558-561a1348d0b2@bastelstu.be> <5f496cf9-8754-b009-9cb5-b978222b2249@bastelstu.be> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0 From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) Hi On 2/16/22 12:39, Go Kudo wrote: >> Is the nextByteSize() method actually required? PHP strings already know > their own length. > > This is a convenience of the current implementation. You already said that you will think of some good ideas, but I'd like to be clear that the convenience of the internal implementation should not be something that affects the user-facing implementation. In fact with the current implementation I can trivially create a memory-unsafety bug: getBytes(8))); Results in: > ==116755== Use of uninitialised value of size 8 > ==116755== at 0x6180C8: php_bin2hex (string.c:111) > ==116755== by 0x6185D2: zif_bin2hex (string.c:220) > ==116755== by 0x79BDB4: ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1312) > ==116755== by 0x8194F0: execute_ex (zend_vm_execute.h:55503) > ==116755== by 0x81ED86: zend_execute (zend_vm_execute.h:59858) > ==116755== by 0x75A923: zend_execute_scripts (zend.c:1744) > ==116755== by 0x69C8C4: php_execute_script (main.c:2535) > ==116755== by 0x8E0B19: do_cli (php_cli.c:965) > ==116755== by 0x8E1DF9: main (php_cli.c:1367) > ==116755== > ==116755== Use of uninitialised value of size 8 > ==116755== at 0x618100: php_bin2hex (string.c:112) > ==116755== by 0x6185D2: zif_bin2hex (string.c:220) > ==116755== by 0x79BDB4: ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1312) > ==116755== by 0x8194F0: execute_ex (zend_vm_execute.h:55503) > ==116755== by 0x81ED86: zend_execute (zend_vm_execute.h:59858) > ==116755== by 0x75A923: zend_execute_scripts (zend.c:1744) > ==116755== by 0x69C8C4: php_execute_script (main.c:2535) > ==116755== by 0x8E0B19: do_cli (php_cli.c:965) > ==116755== by 0x8E1DF9: main (php_cli.c:1367) > ==116755== > string(16) "0000000000000000" For userland implementations you really must derive the size from the returned bytestring. Otherwise it's easy for a developer to create an implementation where nextByteSize() and generate() disagree. Even if the memory-unsafety is fixed, this will result in frustration for the user. For native implementations you can keep some explicit width in the code, if that helps with performance. Best regards Tim Düsterhus