From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id 681533857026 for ; Fri, 2 Dec 2022 16:13:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 681533857026 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x535.google.com with SMTP id l11so7115213edb.4 for ; Fri, 02 Dec 2022 08:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l/A5kmM1irVuDmBIY7ijaQMkSKIWPoAEio2t+lNka10=; b=ZwKp6tQawvsoubtQLTyCN6Jb5TAPWFW5d4i/64ceHFzTF7odqcRppxI6WzAP6X0T0Z y/RfzFyGNWfQMshpppfjQ7NHBr1fLDUXjlQHvjCS+MQf7iv774TtMEK6QyhRB1EJ3BVC eEDHvjRQveZrcSuLOrFUOmqO1tGif3L1DQ2sP4dKT7FCDmXJj6h83rznaPMeh9Z3tvzA WGmpq5fBRHaIUJXN6mAy4Pby7vkT7FKFYZ/+27kepuogepzs/6QRItjYL7REadKTLGSQ fXJDvVKq9Ymz+pNPQct+Uho5ZqrwiwrrpHdkEGQdCYBCFaLJ+tIQYIlw3ho9CboCXfoY u3/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l/A5kmM1irVuDmBIY7ijaQMkSKIWPoAEio2t+lNka10=; b=RJQ7Ug7k0B243PoCOVilrC5ENH5GCu9Qx1LoC6xZS7d4ZZqqtBUnWQKHRUQyiCX2E/ sCfPUy7dXfHTm/v7naL1RcKT+PblzqKwxPMGsCgmBLzKsRGeg0dNw2L+01x4nUzJs15h O2bXUf2ISJBS9d99WXzA0wnngfbB2u+4cggoGsMIZLmrGBTkn4bkdSyyDydLZDkm80Fq Mr3bQ6FVUETv84R+tPdTgR2AgssWWRHr4Nm0WAnhms+iOO71uWnrUw+henrQsQ/y8bVk qd/N7dHqlpbSbK9jTHmwt3z/YBFiI5tfs6hC8PrVHTbSJ+9bm9BLS3sX+pRdtTWhkioJ g3bw== X-Gm-Message-State: ANoB5pluwXMvEm+H73n3+PGAUpVvFTqXHMEy78pSkbqk3s0baRy2j4CW +K5A6TvxnHdALD1rFJC40GoCScnc9w+fbWJPcfs= X-Google-Smtp-Source: AA0mqf7D7BEwg/c+jqIXoauDITRS1gBf1oxITk5PJ6dJac3CwTPU088sK9rWuNyEoEp+KE23avv646jkc5CsIiuWRUo= X-Received: by 2002:aa7:c94a:0:b0:46b:74e1:872c with SMTP id h10-20020aa7c94a000000b0046b74e1872cmr16852817edt.301.1669997601024; Fri, 02 Dec 2022 08:13:21 -0800 (PST) MIME-Version: 1.0 References: <87359xyhsn.fsf@gmail.com> In-Reply-To: From: Jonathan Wakely Date: Fri, 2 Dec 2022 16:13:09 +0000 Message-ID: Subject: Re: Feature request: Warning when .c file gets #include'd To: =?UTF-8?B?SmnFmcOtIFdvbGtlcg==?= Cc: gcc@gcc.gnu.org, Marek Polacek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 2 Dec 2022 at 15:47, Marek Polacek wrote: > > On Fri, Dec 02, 2022 at 03:57:44PM +0100, Ji=C5=99=C3=AD Wolker via Gcc w= rote: > > > > Hi, > > > > I've met a guy that is learning C and got stuck when the linker produce= d > > a screenful of messages about that he did something define multiple > > times. The cause of the problem was trivial: > > > > He did ``#include "something.c"'' in his code. > > > > In the past, I also did this thing multiple times and I would appreciat= e > > a warning produced by the gcc when compiling C/C++ file that includes a > > file ending in .c, .cx, .cpp or .cxx. > > > > What do you think about that? > > > > I would prefer to make this enabled when -Wextra is used. > > The problem is that a lot of beginners don't use -Wextra, so the > warning wouldn't be displayed anyway. Right. If the fact you're including a non-header file (which is **never** done by any tutorials or example code **anywhere**) isn't enough of a discouragement, a warning that nobody ever sees isn't going to help. And there are lots of ways to get the same linker errors. Defining functions in a header file and not making them 'inline' (or 'static inline' or whatever C99 says is the right way to do that) will produce the same results, but your warning wouldn't help. > > Based on my past experience with using .c files in the include > > directive, I can think of these problems. > > > > - Sometimes, I want to include a file that is definitely not a header= , > > but also it is not a stand-alone source file. I personally prefer > > using .inc suffix, but some people possibly terminate the file name= s > > with .c suffix like a source file. > > > > Example: list of enum fields included from a separate file that wa= s > > generated by a script > > > > - In some projects, someone can deliberately want to include another > > source file. For example, this can happen when doing unit tests and > > you do not want to specify the source file name on the command line= . > > Indeed, e.g. elfutils uses this a lot: > #define LIBELFBITS 64 > #include "elf32_xlatetom.c" > > We use including .c in our testsuite a lot as well. Libstdc++ does it in several places: https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dlibstdc%2B%2B-v3/src/c%2B= %2B11/cow-sstream-inst.cc;h=3D8839f4a6f75d608ec911fb99098f5e15ab71f162;hb= =3DHEAD#l29