From nobody Fri Sep 13 12:24:00 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X4tld3Rffz5Wshk for ; Fri, 13 Sep 2024 12:24:13 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X4tld0sXtz4Ft5 for ; Fri, 13 Sep 2024 12:24:13 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x931.google.com with SMTP id a1e0cc1a2514c-846c44bfbe7so400011241.3 for ; Fri, 13 Sep 2024 05:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726230252; x=1726835052; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RXid1k1yWHmLt/uZHimpnJYgulwvZijsBjiPLlxQ29g=; b=UEk8CDjwtkW50lvp1WtO5/gJZuCvUoING+wXh39enAVkHYXql/Lh6rIBN/sKq2MHrZ u0mCFTFzzIDDaLToxC5WDfIMLvOM+pCJ6owR/d9uJrwdbmE3Oq9p3VdfwgoqE8+sTGob w3Ueg5L6jozXDtge+Ug3zzpUDYuqmbEeA3GTQ7hIgDZAakbpX+pJDdniYwF9pncPZe/M Ick4A+XV4q4fNo/m3uPWKEVjSgEEcA0sigsW9Jop5mijOwdFxNC78UO3+Vw/Av7mNtec AKEMp9fniqm1yffd68EvkVx6gDGw58GFiOZfZEpUU/yHOJt9yTziFN91xkhokE9Wp0XK aFww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726230252; x=1726835052; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RXid1k1yWHmLt/uZHimpnJYgulwvZijsBjiPLlxQ29g=; b=ijr2XZT1i4BqwldORFgNG6QgHEAAOGnnKQEDSxv/3443Rxz18gpB6Nd4nB1JIWJ8NN OVJr2AlDnVNyRiA5Nbntx2K6ity7tNiWthqsdLEXPEyNWzRlwRLyz7wHWYp+cgQS8Rv7 V6VMAPfP03fsisLfTSl7w43mfwBfuMU6VSbUTr+UCs275IKqWfQLfXvRhcVoyd1r8Wa/ wehSlkNsLnAAq3IrT6L6U/eGkmzkiBqig04vRk2cCRm3G8xZYTNIzJN4SrtyOsp3xeDg sSiSV2NElro4v0ZYoUJL8SndDRznpXRuOoOXhFyEKZgcQ1yWXCb9iw2VCUPd4JKkbgHb KcEw== X-Gm-Message-State: AOJu0YwmB+Ue/NTKapZC94xN06xrPKUlqwsTb5UFWUeEKv41KJZG1WB5 GU1YKYMraj9ln55kHLeo/7HFzkHP7b7YxhykO6l36sCRjyw4qjiYdTXnyuVgPRPs5nHQATHI86G aODQnmZYlBv0qitpK2u1JPoRHlRe4xIbm X-Google-Smtp-Source: AGHT+IFmykJ+nbK8NiOT+PjCbWxMCzDfihjTcdMQiD4+x9a81swDGgV/wkppyfHc1vUGfQ/u6hS5TYzZLzMdZ9Y7Fl4= X-Received: by 2002:a05:6102:cce:b0:493:b52f:ecb6 with SMTP id ada2fe7eead31-49d4157074amr4497044137.20.1726230251740; Fri, 13 Sep 2024 05:24:11 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <2EE309BF-CE1D-48AD-9C53-D4C87998B4A0@freebsd.org> <2D0F93DC-36DA-4FB9-BFD2-D7678EC03CD7@FreeBSD.org> <9924d197-1b3f-4781-9fe0-20579c8e9066@gmail.com> In-Reply-To: <9924d197-1b3f-4781-9fe0-20579c8e9066@gmail.com> From: Aryeh Friedman Date: Fri, 13 Sep 2024 08:24:00 -0400 Message-ID: Subject: Re: The Case for Rust (in any system) To: Paul Floyd Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X4tld0sXtz4Ft5 On Fri, Sep 13, 2024 at 7:59=E2=80=AFAM Paul Floyd wr= ote: > > > > On 13-09-24 11:40, Aryeh Friedman wrote: > > > > > 1. Fixed allocations are *ALWAYS* safer and more predictable then > > dynamic ones (dynamic ones are undecidable in there nature and > > effects). > > > > 2. Combining fixed allocation with dynamic (under the hood and > > unrequested) allocation is a very bad idea. > > > > 3. It is possible to do all the above safely with arrays and not > > pointers IF the arrays are static but not dynamic. > > > > This implies that if and when you grow/shrink the physical array you > > need to have really tight control on timing and Rust does not provide > > that by putting it all under the hood. > > You aren't being very clear with your vocabulary. In C there are 4 main > kinds of storage. > > Global, static and automatic. These are all of constant fixed size > (except for automatic which can use VLAs since C99 which is of variable > fixed size). Incorrect a pointer by definition points to a memory region of *UNKNOWN* size and it is only the runtime environment that keeps track of how large it is. I doesn't matter if I allocated globally, statically or automatically (or what scope I declared it or if its on the stack or the heap) it is still a pointer to a specific piece of memory and the runtime language environment (all languages including machine have a runtime environment that might not be the same as the machines runtime environment [what I means they can operate without software/firmware hooks that are not pure hardware]). In other words an array is an array and a pointer is a pointer period and the only place they intersect if that an array+index is the base addr of the array+offset. This means that it is the responibility of the caller (at the machine level) to ensure enough memory is reserved for the array. If we need to grow the array at some later point and memory is fragmented we will have to create a new allocation and copy the old array values into it. This is O(n) at best and thus not an atomic operation. > Dynamic, as managed by malloc and family. Can be constant sized or > variable sized. Malloc is not the *ONLY* way to allocate memory at the system level an other way (which I use in my research) is for each function/module to live in it's own VM and at the beginning of it's existence allocate internal RAM to it self from a slice of RAM given to it by the caller. In this case you can use nothing but array notation and still have all the power of pointers (except for their I/O capabilities of addressing fixed/known memory addressed for I/O buffers). > > Which of these is your array that can grow or shrink? Go read CLRS it is a very clear and obvious algorthm the only thing you have to be careful of is it is not O(1) so you need to time it carefully when I do the expanson/contraction instead of just letting the runtime environment do it for you. An extreme case of this going very wrong happened in July 1969 here is the transcript: 4 06 42 10 CC Eagle, Houston. You're GO for landing. Over. 04 06 42 17 LMP (EAGLE) Roger. Understand. GO for landing. 3000 feet. PROGRAM ALARM. 04 06 42 19 CC Copy. 04 06 42 22 LMP (EAGLE) 1201 04 06 42 24 CDR (EAGLE) 1201. 04 06 42 25 CC Roger. 1201 alarm. We're GO. Same type. We're GO.