From nobody Sun Sep 10 12:58:37 2023 X-Original-To: freebsd-arm@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 4Rk8zp0bl4z4s65x; Sun, 10 Sep 2023 12:58:46 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rk8zn5mqQz3DCl; Sun, 10 Sep 2023 12:58:45 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 38ACwb8u013537; Sun, 10 Sep 2023 07:58:37 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1694350718; bh=23LKbuZhxZ330IzoDPq0Rmobyt8gO+qow7yHWojVXl0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=WNXzCurJFcRFkts/7GiinT6IYHp61r6LTed/6nhXL6wAhht20qoXpi95kUB6gfhSj /RNWxPSWRR/oqf7H5/0g/mMev8Gsi+Q7SYId9B9E7V1IKYY1suqnFc5B/Gk9tH+zZv qv3iUKGf+wb18NMnYZQnxhXWTnpA/sdColhYNF3uMppKMli2p3Cs8rbTyWItaQxNM4 kMXEwsv8oyy7245wQ1Zvhayvyp4/NHT+QQhMRKl5VIgefLXkYJ5V8PsadpR7ou6Slj uZdiM3rUAwPz2QdRkaG15bfHG5CCh2ZBsU0lnv5KCxL6/lT4atroekWi7tqRGXyHlD o4wPVh7fGV0Lw== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id k6IfLH29/WTfNAAAs/W3XQ (envelope-from ); Sun, 10 Sep 2023 07:58:37 -0500 From: Mike Karels To: Mark Millard Cc: Martin Matuska , Alexander Motin , Pawel Jakub Dawidek , Glen Barber , Current FreeBSD , FreeBSD-STABLE Mailing List , freebsd-arm Subject: Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char Date: Sun, 10 Sep 2023 07:58:37 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: <96C2F8F3-D3F0-48FC-BEEC-E3C983BD680A@yahoo.com> References: <96C2F8F3-D3F0-48FC-BEEC-E3C983BD680A.ref@yahoo.com> <96C2F8F3-D3F0-48FC-BEEC-E3C983BD680A@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain 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)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4Rk8zn5mqQz3DCl On 10 Sep 2023, at 2:31, Mark Millard wrote: > kyua tests that use the: > > /usr/tests/sys/cddl/zfs/bin/mkfile > > program like so (for example): > > mkfile 500M /testpool.1861/bigfile.0 > > (which should be valid) end up with mkfile > instead reporting: > > Standard error: > Usage: mkfile [-nv] [e|p|t|g|m|k|b] ... > > which prevent the kyua test involved from working. > > Turns out this is from expecting char to be always > signed (so a -1 vs. 255 distinction, here in an > aarch64 context): > > . . . > (gdb) list > 179 /* Options. */ > 180 while ((ch = getopt(argc, argv, "nv")) != -1) { > 181 switch (ch) { > 182 case 'n': > 183 nofill = 1; > 184 break; > 185 case 'v': > (gdb) print ch > $16 = 255 '\377' > (gdb) print/x -1 > $17 = 0xffffffff > (gdb) print/x ch > $18 = 0xff > . . . > > With the mix of unsigned and signed it ends up > being a 0xffu != 0xffffffffu test, which is > always true. mkfile is broken. getopt returns an int, and -1 on end. It never returns 0xff. But mkfile declares ch as char, which truncates the return value -1. ch is a bad (misleading) variable name, although getopt(3) uses it as well (but declared as int). Mike > So the switch is reached as if a "-" prefix was > present (that is not). Then the "option" is classified > as invalid and the usage message is produced. > > Apparently no one had noticed. That, in turn, suggests a > lack of inspected testing on aarch64, powerpc64, > powerpc64le, armv7, powerpc, and powerpcspe. That, in > turn, suggests that kyua test inspection for the likes > of aarch64 is not historically a part of the release > process for openzfs or for operating systems that include > openzfs. > > > === > Mark Millard > marklmi at yahoo.com