From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 813FB1FF15C for ; 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 , Dominik Csapak References: <20240731093604.1315088-1-d.csapak@proxmox.com> <20240731093604.1315088-4-d.csapak@proxmox.com> <16cff3a6-15c3-4078-ba1b-2764e8287478@proxmox.com> Content-Language: en-GB From: Thomas Lamprecht 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" 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