From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pbs-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id 813FB1FF15C
for <inbox@lore.proxmox.com>; Wed, 7 Aug 2024 17:02:00 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id A5A059815;
Wed, 7 Aug 2024 17:02:09 +0200 (CEST)
Message-ID: <8100f051-ec76-4a6e-9536-cc9cb846bb72@proxmox.com>
Date: Wed, 7 Aug 2024 17:01:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com>
References: <20240731093604.1315088-1-d.csapak@proxmox.com>
<20240731093604.1315088-4-d.csapak@proxmox.com>
<fa70b3f1-e7d0-4cd2-ad07-65a0cfa0f892@proxmox.com>
<cf4c39e9-87d2-41c2-80ef-a7373d91339d@proxmox.com>
<ba577e57-cc74-428a-90ea-f298f3b81a03@proxmox.com>
<16cff3a6-15c3-4078-ba1b-2764e8287478@proxmox.com>
Content-Language: en-GB
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <16cff3a6-15c3-4078-ba1b-2764e8287478@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.051 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pbs-devel] [PATCH proxmox-backup v2 3/4] datastore: data blob:
increase compression throughput
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pbs-devel-bounces@lists.proxmox.com
Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com>
Seems I forgot to reply-all, so while this is outdated (i.e., already implemented
by Dominik in v3) it still is nice to have the list complete, for the record so
to say.
On 02/08/2024 14:38, Dominik Csapak wrote:
> ---
> fn map_error_code(code: usize) -> io::Error {
> let msg = zstd_safe::get_error_name(code);
> io::Error::new(io::ErrorKind::Other, msg.to_string())
> }
> ---
>
> which calls this:
>
> ---
> pub fn get_error_name(code: usize) -> &'static str {
> unsafe {
> // Safety: assumes ZSTD returns a well-formed utf8 string.
> let name = zstd_sys::ZSTD_getErrorName(code);
> c_char_to_str(name)
> }
> }
> ---
>
> which is part of the zstd api and at the end it maps the error code like this:
>
> ---
> ERR_STATIC ERR_enum ERR_getErrorCode(size_t code) { if (!ERR_isError(code)) return (ERR_enum)0; return (ERR_enum) (0-code); }
> ---
>
> with that result, it maps the code to a string...
>
> which matches what i get, since
>
> 2^64 - 70 = 18446744073709551546 [0]
>
Thanks for looking into this and providing the explanation.
> but, i'm really not sure if we could rely in that since the function is in a 'error_private.c' which seems to me like it's an implementation detail only?
>
Yeah, it's not ideal... But it could be made safe enough by adding a test that runs
on build and triggers this error explicitly by passing a way to small target buffer,
that way we can notice when this internal error changes, which is IMO not _that_
likely, at least not during the same major Debian release, as there we normally
only get critical bug and security fixes, and while I don't want to curse it,
but I'd really be surprised if this particular code would change semantics, as
it's hard to envision that the widely used `- code` pattern to return errors
in C ABIs should be part of such a critical flaw.
And yeah, while that is not the interface I'd wish for, it doesn't really feels
significantly worse to me than doing matching on error string, as those aren't
guaranteed to be 100% stable either I'd think.
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel