From owner-svn-src-head@freebsd.org Fri Aug 23 22:05:39 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B387CCF8E3 for ; Fri, 23 Aug 2019 22:05:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Fb7Q46n1z4FYj for ; Fri, 23 Aug 2019 22:05:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id m10so9562034qkk.1 for ; Fri, 23 Aug 2019 15:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KzMGq7lpQxwmhW5C/IZVGmln+AiogLi0Dj1KvKeE29s=; b=ltRHLJTXDC+Cvw2LlXK0Tndc9bASn0ZTGQ0XdrREBVr1In/xROdmJ53yfaOhLR10rG gMQHYnDjpUlnpAlmgoSQGZIUmDnvLbA7cOuUB5tvgW1GIasW/TGqvBr2l2H0kz5XoMEY HiMzEOZusIeyJK/RqCWjb+cTylouchxb5zv0Wmy+YjhWsVwIUtTOw5vOUuv0HAQSVcps mK4QNIJ1g2i2KDLn1Dk7DigqFWMTyxjS2FHwdtzxAPkgBr6JG72O/aeXt1/4lMsjmPwF P2sV9mprK7Yv2aWVCoOp2GcX1Uk7bG9VegonvhDiAh6INTL5PTwvJVyTsFQYyqUY/FKM FKMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KzMGq7lpQxwmhW5C/IZVGmln+AiogLi0Dj1KvKeE29s=; b=NhvKSyTzpfQiZuA69u+L6cnO3fSTB2EH7H4J/pMqxkGxKEq2wfQ44+zXCxhoUhCBT8 SJnzoiB+SEyc78n2zMbywxpjZlR+RbC4OX78Bst8Uq4ATpU7VE+TwIKc8xa0vqukXbYx Ux/DxjKM79rTo1FXJuPIpmiICXHNOXjLtKk/hGSfKjowDWBCuhPMCGKVoJ7xOEhf1Z4j nnZThRbe/BZG+pN+bR5R0pLL/fb6BIt9KOiAA0bZJYe9+NKqO76CAxR6OFSaJjFbilyf 2LdJXIEdJR1dBYTenJfOvuemr68WUkaUNy9KgMVzhvdJjvG9F1YGTlSgQpu+uPc8wY1w J4wg== X-Gm-Message-State: APjAAAXYav7jk7vL0RDhaDLVWumH+T0gOfgAKdWNeHxwZ2lEv8vWGAkA mXWUszYfUqybNGGMsvUtgFuIyttjYivrmiL1gD0IDg== X-Google-Smtp-Source: APXvYqzHLjmNW0awVbjp203tRNPg2ccexaqjwTbCl2oA8zda7jzd4BT4BWV7x2+elNZ3E4CMYrNUkapUMuZ4pQ9jGMU= X-Received: by 2002:a37:4b03:: with SMTP id y3mr6498895qka.215.1566597937184; Fri, 23 Aug 2019 15:05:37 -0700 (PDT) MIME-Version: 1.0 References: <201908220002.x7M028Jh070116@repo.freebsd.org> <0b9d1aa1-d328-30bc-b939-f1407e236855@FreeBSD.org> <3EE09B22-254B-4415-8865-D9542122ACA5@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Fri, 23 Aug 2019 16:05:26 -0600 Message-ID: Subject: Re: svn commit: r351364 - in head/sys: crypto/blowfish crypto/chacha20 crypto/des opencrypto To: "Conrad E. Meyer" Cc: "Bjoern A. Zeeb" , Li-Wen Hsu , John Baldwin , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 46Fb7Q46n1z4FYj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ltRHLJTX; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; RCVD_IN_DNSWL_NONE(0.00)[d.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.93)[ip: (-9.38), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.34), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:05:39 -0000 On Fri, Aug 23, 2019 at 12:26 PM Conrad Meyer wrote: > At expected peril of wading into a thread >4 emails deep, > > @Warner, modern GCC reports a similar warning; it just doesn't become > an error (at least in CI?). I'm not sure of the mechanism. Maybe > CI-specific? Old GCC didn't have a -Wno-error for -Wcast-qual, so > -Wcast-qual + -Werror there produced an error; that's why > $NO_WCAST_QUAL in conf/kern.mk is defined to -Wno-cast-qual for old > GCC but -Wno-error=3Dcast-qual for newer compilers. That said, this > file does not appear to be compiled with ${NO_WCAST_QUAL} either way. > Yea. I'm unsure. It's an odd warning, and an odd way to get around it. In general, nobody cares about gcc 4.2.1, so pinning implementing that belief to this specific bug may have been unwise. I just assumed newer versions wouldn't warn on this, but I saw on IRC that the types are stupidly different... > @Bjoern, > > So... why does GCC warn about this? key is const uint8_t*. The cast > is to const des_cblock *. I think the problem is that des_cblock is > defined as 'unsigned char [8]', so a 'const des cblock *' is actually > a 'const unsigned char**'? So... I think basically the entire des > subsystem may be accidentally using the wrong pointer level > throughout? The constify change just exposes that because correct > const-preserving cast of 'const foo*' to 'foo**' would be 'foo * const > *' (if I'm understanding this correctly). > > Maybe one more reason to excise des from the tree. Ha! No comment :) Warner > Best, > Conrad > > > On Fri, Aug 23, 2019 at 9:59 AM Bjoern A. Zeeb wrote: > > > > On 23 Aug 2019, at 16:48, Warner Losh wrote: > > > There's a lot of -Wno-error and -Wno-error=3DXXX sprinkled in our bui= ld > > > for > > > gcc 4.2.1 today, so we see the warnings but aren't stopped by them. M= y > > > changes take a big hammer and add a global -Wno-error to CFLAGS last > > > to > > > make this the behavior on gcc 4.2.1 platforms. > > > > > > Yes, but that didn=E2=80=99t answer my questions. It doesn=E2=80=99t h= elp to try to > > avoid undefined C behaviour. > > > > That jenkins build seems to use the toolchain from ports and with that > > gcc 6.4.0. > > > > We see the same warning but it didn=E2=80=99t error as it seems to have= done > > for other architectures with the in-tree gcc with the same warnings: > > > > In file included from /workspace/src/sys/opencrypto/xform.c:94:0: > > /workspace/src/sys/opencrypto/xform_des1.c: In function 'des1_setkey': > > /workspace/src/sys/opencrypto/xform_des1.c:102:15: warning: cast > > discards 'const' qualifier from pointer target type [-Wcast-qual] > > des_set_key((const des_cblock *) key, p[0]); > > ^ > > In file included from /workspace/src/sys/opencrypto/xform.c:95:0: > > /workspace/src/sys/opencrypto/xform_des3.c: In function 'des3_setkey': > > /workspace/src/sys/opencrypto/xform_des3.c:103:15: warning: cast > > discards 'const' qualifier from pointer target type [-Wcast-qual] > > des_set_key((const des_cblock *)(key + 0), p[0]); > > ^ > > /workspace/src/sys/opencrypto/xform_des3.c:104:15: warning: cast > > discards 'const' qualifier from pointer target type [-Wcast-qual] > > des_set_key((const des_cblock *)(key + 8), p[1]); > > ^ > > /workspace/src/sys/opencrypto/xform_des3.c:105:15: warning: cast > > discards 'const' qualifier from pointer target type [-Wcast-qual] > > des_set_key((const des_cblock *)(key + 16), p[2]); > > ^ > > -- > > > > > > > > To me this means that we treat different versions of compilers (in-tree > > and out-of-tree, gcc vs. clang) too different. > > > > If two versions of gcc (before your commit) gave the same warning I > > would have expected them to equally fail and not one fail and one pass? > > > > My question was: why was that the case? > > > > /bz > > >