Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5439046ybi; Tue, 4 Jun 2019 06:44:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqzeGGuXq6FhfglusOSmR5aNAnejwMGSf2ClyjDbbyR23ZRnSlEssWOInhIzbpeJch+WlQvI X-Received: by 2002:a63:e10d:: with SMTP id z13mr14381172pgh.116.1559655891492; Tue, 04 Jun 2019 06:44:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559655891; cv=none; d=google.com; s=arc-20160816; b=yW0Dhaa9kBz55Yz6bQ3vHCiSWJhQGU0xsJacOkEsMndRRd3QXGUPBRC2w5kKov2HoN 651IalHGKiYeyDZ1XkxAY0Sx0z1ByGDs4my44Clm3jC7Jnszt/T8kcuGb2d1+jM7LAzK ZlLIfw+nkHESmNB3jmdo5a9qfJg7kYRXIAFOsnzZ+7twlrbwWJ0Jb4Wryyo/llYSgheL uVEQlhaJlqvXCy/F58AfzBMgLkiFEMNkLrssq7svkeGwSi4V6lRtbD/VySamfW4Dpari ud2OFIPhTgjRPbxYUtLkTDTzT9eOZxHv0rvffCA3rqzimy61wGb+FU27lVVhyZ7iGOgl IRaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=FeEXQL2qVvcyG3us06Ohc2cX85cdhd109Y/feADWFvw=; b=0PheAb7bj8Q/yiypYCwAn2oYXJxV9sb5aJmoX+WMm5qgRaJke1Db3h1vdRuoI5HxU1 LzyatcWYgowNXeNZkUOvlOBTguzwjx+PcvJfj8f5jhObFjx5pT7aj96ZcSB/OhV/Aqfo ZuIF2F5r8ManbHFx5P6HFz0GA5cHzzH76siY9Tq3hUE0bBoRN2bfSEdgBw5Gjq8udmEI xVJ5z+oe/0jsR/kZZIR1SjEDZlRvpgdXudo92a9nydj6rxYWzyLGxCBVhZKraPZy4mMq TwWxZuGy8Qy+di1j+P0eehFlsw+m86j7YcHIk62cVe8oXs6NRW3a282AZ29mvj9FeWXm VYnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=enrOrWMy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w28si8652912pgl.218.2019.06.04.06.44.33; Tue, 04 Jun 2019 06:44:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=enrOrWMy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727519AbfFDNmS (ORCPT + 99 others); Tue, 4 Jun 2019 09:42:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:48390 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727129AbfFDNmS (ORCPT ); Tue, 4 Jun 2019 09:42:18 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2A27424B0A; Tue, 4 Jun 2019 13:42:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559655736; bh=bZNqVO8f2ylblrO+c28v5AyhWdCQSWSKn5ngf4Aj5NE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=enrOrWMyuu5hZJrGcow0Dqzo9DGi2h086EaQngbQdQHsC81UHjNz5BLsqZuzI6hLP QEFG1Y3IHq043mikzia76U0mRvrrmRHW9V3jvNBFAdihVK/YAEZIm3LwgCSbOwUH2A XrnZS/VaMwtJ/MA4/h9Nadbue81MOSrRhf1SMeHU= Date: Tue, 4 Jun 2019 15:42:13 +0200 From: Greg KH To: Masahiro Yamada Cc: Arnd Bergmann , Joe Perches , Linux Media Mailing List , Mauro Carvalho Chehab , Thomas Gleixner , Randy Dunlap , Linux Kernel Mailing List Subject: Re: [PATCH] media: do not use C++ style comments in uapi headers Message-ID: <20190604134213.GA26263@kroah.com> References: <20190604111334.22182-1-yamada.masahiro@socionext.com> <8cf48e20064eabdfe150795365e6ca6f36032e9f.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 04, 2019 at 09:48:12PM +0900, Masahiro Yamada wrote: > On Tue, Jun 4, 2019 at 8:55 PM Arnd Bergmann wrote: > > > > On Tue, Jun 4, 2019 at 1:23 PM Joe Perches wrote: > > > > > > On Tue, 2019-06-04 at 20:13 +0900, Masahiro Yamada wrote: > > > > On the other hand, uapi headers are written in more strict C, where > > > > the C++ comment style is forbidden. > > > > > > Is this a real problem for any toolchain? > > > > There is likely some code that is built with -Wpedandic -Werror --std=c89 > > or similar. Since glibc allows this combination for its own headers, it seems > > best to also allow it in kernel headers that may be included by libc headers > > or by applications, at least where it does not hurt. > > > > Realistically though, we probably assume c99 or gnu89 in user space > > headers anyway, since there is no 'long long' in earlier standards. > > > > Arnd > > In fact, I detected this issue by the following patch: > https://patchwork.kernel.org/patch/10974669/ > > When I worked on it, I wondered which > c-dialect flags should be used. > > This code: > > > # Unlike the kernel space, uapi headers are written in more strict C. > > # - Forbid C++ style comments > > # - Use '__inline', '__asm__' instead of 'inline', 'asm' > > # > > # -std=c90 (equivalent to -ansi) catches the violation of those. > > # We cannot go as far as adding -Wpedantic since it emits too many warnings. > > # > > # REVISIT: re-consider the proper set of compiler flags for uapi compile-test. > > > > UAPI_CFLAGS := -std=c90 -Wpedantic -Wall -Werror=implicit-function-declaration > > Even "-std=c99 -Wpedantic" emits lots of warnings. > > > > I noticed one more thing. > > There are two ways to define fixed-width type. > > [1] #include , __u8, __u16, __u32, __u64 > > vs > > [2] #include , uint8_t, uint16_t, uint32_t, uint64_t > > > Both are used in UAPI headers. > IIRC, was standardized by C99. > > So, we have already relied on C99 in user-space too. Just because we have relied on it in the past, does not mean we need to keep relying on it. I have had numerous complaints over the years from libc authors that our uapi headers are _NOT_ able to be directly consumed by them. They all end up having to fix things up and include local "sanitized" copies. So any work we can do here to make them more sane and work properly everywhere is a good thing, as right now, they are broken. thanks, greg k-h