public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Feature request: Warning when .c file gets #include'd
@ 2022-12-02 14:57 Jiří Wolker
  2022-12-02 15:46 ` Marek Polacek
  0 siblings, 1 reply; 3+ messages in thread
From: Jiří Wolker @ 2022-12-02 14:57 UTC (permalink / raw)
  To: gcc


Hi,

I've met a guy that is learning C and got stuck when the linker produced
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 appreciate
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.

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 names
    with .c suffix like a source file.

    Example:  list of enum fields included from a separate file that was
              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.

If you accept that, I can try to implement that. (That would be my first
contribution to this project and I do not know gcc codebase, but it
looks like a relatively simple change.) Do you think that it would need
a copyright assignment?

Thanks,
Jiří

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Feature request: Warning when .c file gets #include'd
  2022-12-02 14:57 Feature request: Warning when .c file gets #include'd Jiří Wolker
@ 2022-12-02 15:46 ` Marek Polacek
  2022-12-02 16:13   ` Jonathan Wakely
  0 siblings, 1 reply; 3+ messages in thread
From: Marek Polacek @ 2022-12-02 15:46 UTC (permalink / raw)
  To: Jiří Wolker; +Cc: gcc

On Fri, Dec 02, 2022 at 03:57:44PM +0100, Jiří Wolker via Gcc wrote:
> 
> Hi,
> 
> I've met a guy that is learning C and got stuck when the linker produced
> 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 appreciate
> 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.
 
> 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 names
>     with .c suffix like a source file.
> 
>     Example:  list of enum fields included from a separate file that was
>               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.

So I'm afraid this would get -1 from me personally, sorry.

> If you accept that, I can try to implement that. (That would be my first
> contribution to this project and I do not know gcc codebase, but it
> looks like a relatively simple change.) Do you think that it would need
> a copyright assignment?

I think it would.

Thanks,
Marek


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Feature request: Warning when .c file gets #include'd
  2022-12-02 15:46 ` Marek Polacek
@ 2022-12-02 16:13   ` Jonathan Wakely
  0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Wakely @ 2022-12-02 16:13 UTC (permalink / raw)
  To: Jiří Wolker; +Cc: gcc, Marek Polacek

On Fri, 2 Dec 2022 at 15:47, Marek Polacek wrote:
>
> On Fri, Dec 02, 2022 at 03:57:44PM +0100, Jiří Wolker via Gcc wrote:
> >
> > Hi,
> >
> > I've met a guy that is learning C and got stuck when the linker produced
> > 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 appreciate
> > 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 names
> >     with .c suffix like a source file.
> >
> >     Example:  list of enum fields included from a separate file that was
> >               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=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/cow-sstream-inst.cc;h=8839f4a6f75d608ec911fb99098f5e15ab71f162;hb=HEAD#l29

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-12-02 16:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-02 14:57 Feature request: Warning when .c file gets #include'd Jiří Wolker
2022-12-02 15:46 ` Marek Polacek
2022-12-02 16:13   ` Jonathan Wakely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).