From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4994 invoked from network); 1 Feb 2023 00:52:00 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 1 Feb 2023 00:52:00 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 249DE4247C; Wed, 1 Feb 2023 10:51:39 +1000 (AEST) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 5846A42476 for ; Wed, 1 Feb 2023 10:51:34 +1000 (AEST) Received: by mail-oi1-f171.google.com with SMTP id p133so14427866oig.8 for ; Tue, 31 Jan 2023 16:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SHDlqbYeD57MaO+3CFs2gD23b+q/xXlQWzrR7h7uORA=; b=FaddMHwCdFkuOCnt8j5+xxEAtMfOKip5YIGetaanlyNOh49ox2tnXg5/lwKfNeC9ar oqq1cnuamJfQdeSC/vPAPm1+WGDTctNUEvNg93wAaqjbsXb8RJk9jx9ubWkI/O+tRXjG sheA0yRHK+CSRr/IvUqm8E3eFY/QO+DA7xvck+XzoaNMs8T2LXsLhwr2bt79D6KjJtDM 73p0sdeF5nQN1dBn830vP1H0+IfFE0d+bBegcsxGvEKnWcpop3ZvjjiakASkk6nyDD/w 8MMgoffSRvuNyCu5hbBbkb+yltSHzXpoEHPlSJOYn+LEjo6UIquKFXSW80golGaE8S8h oKUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SHDlqbYeD57MaO+3CFs2gD23b+q/xXlQWzrR7h7uORA=; b=F45A5HET01u7jslm6ERE4L2WRgTP5L8w651rbzgu3pFnzSmc0Lm1m/s6GvVHb3cbMb vkbKlzNh2Eitfu+bRQWRALwvtygR0JLkK6eXzpKv5kdhKccDwL3vxEeDMY1YryQNanMA m5//WOk1/w1bC47dCK7ub9uo3gVpo2xXeySGV2p5A3WuMoTLa2zRQi/3Ovl+W1uO4WPH XAwf+DYW0tq15NlX5+XJmNa5BnGRsuYDZSHUSyUKC/D297nE4bXPgzasF5ZCI0f71Hs6 Pq3lWFA5RKBIq0ZzWdSaR/Lv/4+klBbklmqOExDCiN3LQVuXiSg2fX7aB+VJrh0wvDKc Y/NA== X-Gm-Message-State: AO0yUKUHbNltKNJ+ZirfjXFl3y7/Y0R95/BLUJqOr35ESqj/y5RamKsj DLKNlE2H30OAKhdFkjAphdfKMWLKRAw= X-Google-Smtp-Source: AK7set/hBfihy15FN3nQ/bPekq5i5EHRcXfWsndzTtLq3NZfitlDR1lcMhpvBkVda8Ib3ozJ55odSw== X-Received: by 2002:aca:b155:0:b0:359:c6f0:5086 with SMTP id a82-20020acab155000000b00359c6f05086mr5586825oif.56.1675212632537; Tue, 31 Jan 2023 16:50:32 -0800 (PST) Received: from [192.168.254.25] (h201.47.20.98.static.ip.windstream.net. [98.20.47.201]) by smtp.gmail.com with ESMTPSA id q125-20020aca5c83000000b0036f02656fa5sm6423067oib.34.2023.01.31.16.50.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Jan 2023 16:50:31 -0800 (PST) Message-ID: <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com> Date: Tue, 31 Jan 2023 18:50:31 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: tuhs@tuhs.org References: <20230201004023.rHE9j%steffen@sdaoden.eu> From: Will Senn In-Reply-To: <20230201004023.rHE9j%steffen@sdaoden.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 3HP7L6J2Q7K57IYKX6QAORHDZR4OZX3A X-Message-ID-Hash: 3HP7L6J2Q7K57IYKX6QAORHDZR4OZX3A X-MailFrom: will.senn@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Algol rules: was something about Rust is not C++ List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Well, I just read this as Rust is dead... here's hoping, but seriously, if we're gonna go off and have a language vs language discussion, I personally don't think we've had any real language innovation since Algol 60, well maybe lisp... sheesh, surely we're in COFF territory. On 1/31/23 6:40 PM, Steffen Nurpmeso wrote: > ron minnich wrote in > : > |That example was a simplified bit of code from a widely used code base. All > |I need to do is change the function g go a pointer to function, or have it > |be provided by a .so, and all bets are off. > | > |In any event, the important thing here is not that y should be initialized, > |or should not; it's that it is not possible to get a consistent answer on > |the question, from people who have been writing in C for decades. > > I find the syntax just terrible. (I have not programmed with it.) > I mean annotations are for the better, ok, (but i luckily get away > with only "const" and "volatile" (and "mutable"), and leave things > like "restrict" be a good man). Johannes Lundberg i think it was > who then left FreeBSD (?) but pointing to a Rust program > he had written (i cannot find the reference), that was a few years > ago (i looked once i composed this message first, it might even > had been as early as 2017!), and i was lucky i do not have to deal > with it. > > Even nim-lang.org that at least converted its code to plain C back > in the day when it was still called Nimrod is too heavy for me now, > but claims to be hard realtime aware etc. It at least tries to > give programmers some syntactic sugar that makes people happy when > they look at the screen for 7 hours (underpaid) or 16 hours > (over-ambitioned). Like the only python thing i like, the > syntax sugar. But as languages grow they get more and more > "refined", and now i read things like > > type > BinaryTree*[T] = ref object # BinaryTree is a generic type with > # generic param `T` > le, ri: BinaryTree[T] # left and right subtrees; may be nil > data: T # the data stored in a node > > proc newNode*[T](data: T): BinaryTree[T] = > # constructor for a node > new(result) > result.data = data > > which gets me off a bit and makes me think that "hey, maybe > Objective-C is not really the worst thing" (despite the syntax). > > I do not know. Everything beyond a small monolithic > self-contained thing is a problem per se. You can then unit test > atomically, and if thousands of modules do that, you plug them to > a better whole. But that also not a good answer, all those flakes > that live their own life, many maybe even in remote locations out > of any control. > > You could have a language which hard fixates all the call chain, > or you could have tools which bring this to a small and simple > language which does not offer it. A compiler can figure out which > variables are assigned etc and could create in-object-file > annotations which the linker automatically verifies. > Of course there are many code paths through functions. > > Back in 2009 when i bought the one Apple i wanted to have i tried > out their Development software, which i think required internet > access. All the pop-ups and titles, i think it (later?) could > compile on-the-fly and inject the new object in the running tested > application, etc. > > And then there are semantic description languages like interface > builders, where robots create the actual code. So then you could > have Corba interface descriptions / DBUS and plug it all via it. > > Then Rob Pike says "make it a string" (more or less), and luckily > i do not have dyslexia. > > Maybe Qt has a good answer by not only not banishing the > C preprocessor, but introducing another one on top. > So then the compiler can analyze the code and generate a correct > variable-state-at-function-call-time state that a dynamic linker > could then verify against the consumer or producer (whatever is > needed) of linked modules, that link modules, that link modules, > all of which are subject to replacements due to development > iterations, bug patches etc, ie, new releases. > > As in, the library versioning that is used for ELF object files, > today often even linker scripts which furtherly diversify this, > offer are not enough, they do not do this. They only bundle > a name to a library version, or multiple (as in > > 1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3 > 33 FUNC GLOBAL DEFAULT 13 realpath@GLIBC_2.2.5) > > I do not know how Rust deals with this. Is it at all possible to > fixate all the call chain over all possibly involved dynamics? > What do i gain from initializing an object with a default value if > that default value is not not not not one of the values that > i expect after some external function is called? > > Sure i not rarely see patches fly by where one more memset(,0,) is > used to fully initialize a struct / prevent memory address > disclosures (i only track BSDs). > And there are still patches that fix bugs on old code that > sometimes is twenty years or more, say zlib or tzcode. > And then there are compiler bugs that bring in bugs -- that is not > avoidable, even if the documentation is clear and obvious like > > /* The application can compare zlibVersion and ZLIB_VERSION for consistency. > If the first character differs, the library code actually used is not > compatible with the zlib.h header file used by the application. This check > is automatically made by deflateInit and inflateInit. > */ > > That is only graspable by a human programmer that reads it. Rapid > application development that surely is not. > (And actually i am not sure this is really true. But i personally > would hope for it. It is more earthy, and has more blood, sweat > and tears.) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt)