From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 08 Jul 2024 18:16:26 -0700 Received: from mail-yb1-f186.google.com ([209.85.219.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sQzSz-0005JR-PP for bitcoindev@gnusha.org; Mon, 08 Jul 2024 18:16:26 -0700 Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e02a4de4f4esf8748531276.1 for ; Mon, 08 Jul 2024 18:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1720487780; x=1721092580; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=j7lUuXc9s6jRNAd0qeV6gYuL7MS5+DVHp1lgWxvSqfk=; b=MbqB4LTlZy9BtcXHEWveCDMX3KPZ1zKOuXA5I/Gp3PAUcrDEg6mhJoCk73W2h2qGW+ a54XD/jfQ1EewLBnYX95BaM7rZgwgWxXuWAY5F9nVr5wbHhka8AW7N2u8UYECGUL60Gn eTwq5SAieENgGHbWjyvHJjBDamuNFaE9C6eTuB7lrpov6fEmAUtb1IEIYQz9zgy0Ap/f S8DHZHAHVWNF0D5bdWUAqL9ZKtItbQ73CHn/vhM10rPdpOv0vg/IhH+IMm26rDT4v3UM 12CtZXs0A5yDbl8blmAAjF881FwCuCgeWjM6jy0K7V98gYv3gLBKSm5EkhpZPx5vXcS0 6ihw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1720487780; x=1721092580; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=j7lUuXc9s6jRNAd0qeV6gYuL7MS5+DVHp1lgWxvSqfk=; b=NT+Ku8LUDjahX8coYW5j9o1keIuI/COH//VSSOsuOIxER7K0hDEUjMeSY+yfD+ZUo+ bEPzACr003H9IE8Mli4DNAjiJsBH7sHaXBkcHKLRLDz+WAYbfHy/PZqUNfRCUiU7Lxw2 YKdpRpIlnRtQbUqqQrhYTo4sBWNiNPybSQX/EXkdzq/mgxaDcrYQIR7TFnV8LkYuWYmS Rd8j5uTiQTNTiWSJjJiLtu1rtA6aIp/xQpCFY5DJvJLJEYbNvcWJ3gd5L8tI3Mm6l/WF YQ9xnUnv7npzRehNsaOsCvvR0fKwu9jd5cQk39tUQZEbq+XWJ9o4XnbBU90cFYlRmrUB xzWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720487780; x=1721092580; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=j7lUuXc9s6jRNAd0qeV6gYuL7MS5+DVHp1lgWxvSqfk=; b=SQ9S/KpQBd2G7/BAuBrQGq3uvteC8kckHGJ1anb6mX6WIDpvfXRWiaWJ/gZhf0Dqoh u2TgWtqtulA9dsoQWM2DOzBa5kA7iLaM94cRUoSEV2Xi7nEy8OTnS5UUib1kR/fQyBIg hrXLPNguPNOn08ZKrVmMJYcvSx6gpF3ZRuuSB1iaTwowXoNM1Gi1l2qbX0gVK4Gz+dmf Dz5Iq+cAWBl9QsAsL/jDvu4LNQoSLTWQiYs73zBPkmV91ohTz6DvGNd/7r7HVji1Lafo oYGi8RKB1wTlOkdSBF+cC/idBUc4Ps+MBKm5RLT7tnyyQgGq48SkjDAIo6AKfx09spb6 Ug5g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXEQdpW/x87kkzPZKJMhM9AOglD2dfxUuT7cKWX+Y4wsxCTlTyBxZZXx0VuzGf4IzxropfGw1nNoMyjSnpSz2zwPbEgfPs= X-Gm-Message-State: AOJu0YwSmQKQvYH07A1wb4PTngNAD85gcnGsCqwTw8S+TsbLr823Ij4r FxLUca8tYlFoP8UVy2G9q1woruw0k80Mgv2Ty3Ym7fiGBkqoexgY X-Google-Smtp-Source: AGHT+IGoIAlyGULIgvPAQB8ZgdYQKD9H+QfFAznM9y4/UaX9lq6Y6YfeM9A4TuAAcajaNwpclRBP+Q== X-Received: by 2002:a25:2f8f:0:b0:e03:4fcf:d77e with SMTP id 3f1490d57ef6-e041b0627damr1714790276.24.1720487779800; Mon, 08 Jul 2024 18:16:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1006:b0:e03:37d1:efbd with SMTP id 3f1490d57ef6-e03bd07dfe0ls6291844276.2.-pod-prod-04-us; Mon, 08 Jul 2024 18:16:18 -0700 (PDT) X-Received: by 2002:a05:690c:7487:b0:62c:fb55:aeab with SMTP id 00721157ae682-658f07d56d9mr677047b3.8.1720487778474; Mon, 08 Jul 2024 18:16:18 -0700 (PDT) Received: by 2002:a05:690c:4289:b0:63b:c3b0:e1c with SMTP id 00721157ae682-6514011671ams7b3; Thu, 4 Jul 2024 07:46:00 -0700 (PDT) X-Received: by 2002:a05:6902:2b87:b0:e03:6556:9fb5 with SMTP id 3f1490d57ef6-e03c1b7fa93mr96959276.11.1720104359933; Thu, 04 Jul 2024 07:45:59 -0700 (PDT) Date: Thu, 4 Jul 2024 07:45:59 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com> <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com> <9a4c4151-36ed-425a-a535-aa2837919a04n@googlegroups.com> <3f0064f9-54bd-46a7-9d9a-c54b99aca7b2n@googlegroups.com> <26b7321b-cc64-44b9-bc95-a4d8feb701e5n@googlegroups.com> <607a2233-ac12-4a80-ae4a-08341b3549b3n@googlegroups.com> <3dceca4d-03a8-44f3-be64-396702247fadn@googlegroups.com> <301c64c7-0f0f-476a-90c4-913659477276n@googlegroups.com> <33dfd007-ac28-44a5-acee-cec4b381e854n@googlegroups.com> Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_238956_1464158660.1720104359718" X-Original-Sender: eric@voskuil.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_238956_1464158660.1720104359718 Content-Type: multipart/alternative; boundary="----=_Part_238957_1272403788.1720104359718" ------=_Part_238957_1272403788.1720104359718 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > This is why we don't use C - unsafe, unclear, unnecessary. Actually, I think libbitcoin is using its own maintained fork of secp256k1,= =20 which is written in C. We do not maintain secp256k1 code. For years that library carried the same= =20 version, despite regular breaking changes to its API. This compelled us to= =20 place these different versions on distinct git branches. When it finally=20 became versioned we started phasing this unfortunate practice out. Out of the 10 repositories and at least half million lines of code, apart= =20 from an embedded copy of qrencode that we don=E2=80=99t independently maint= ain, I=20 believe there is only one .c file in use in the entire project - the=20 database mmap.c implementation for msvc builds. This includes hash=20 functions, with vectorization optimizations, etc. =20 For sure, I wouldn't recommend using C across a whole codebase as it's not= =20 memory-safe (euphemism) though it's still un-match if you wish to=20 understand low-level memory management in hot paths. This is a commonly held misperception. It can be easier to use C++ or Rust, though it doesn't mean it will be as= =20 (a) perf optimal and (b) hardened against side-channels. Rust has its own set of problems. No need to get into a language Jihad=20 here. My point was to clarify that the particular question was not about a= =20 C (or C++) null pointer value, either on the surface or underneath an=20 abstraction. e=20 --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/a76b8dc5-d37f-4059-882b-207004874887n%40googlegroups.com. ------=_Part_238957_1272403788.1720104359718 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> This is why we don't use C - u= nsafe, unclear, unnecessary.

Actually, I think libbitcoin is using its own maintained fork of = secp256k1, which is written in C.

=
We do not maintain secp256k1 code. For years that library carried the = same version, despite regular breaking changes to its API. This compelled u= s to place these different versions on distinct git branches. When=C2= =A0it finally became versioned we started phasing this unfortunate practice= out.

Out of the 10 re= positories and at least half million lines of code, apart from an embedded = copy of qrencode that we don=E2=80=99t independently maintain, I believe th= ere is only one .c file in use in the entire project - the database mmap.c = implementation for msvc builds. This includes hash functions, with vectoriz= ation optimizations, etc.
=C2=A0
For sure, I wouldn't recommend using C across a whole codebase as = it's not memory-safe (euphemism) though it's still un-match if you wish to = understand low-level memory management in hot paths.

This is a commonly held misperception.
It can be easier to use C++ or Rust,= though it doesn't mean it will be as (a) perf optimal and (b) hardened aga= inst side-channels.

Rust has = its own set of problems. No need to get into a language Jihad here. My poin= t was to clarify that the particular question was not about a C (or C++) nu= ll pointer value, either on the surface or underneath an abstraction.
=

e=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/a76b8dc5-d37f-4059-882b-207004874887n%40googlegroups.com.=
------=_Part_238957_1272403788.1720104359718-- ------=_Part_238956_1464158660.1720104359718--