New file extension

New file extension

[Gabriel Dos Reis]

Hi,

I would like to suggest that new implementation files have
the '.cc' extension, unless they are meant to be processed
with a C compiler.  (I am not proposing wholesale renaming.)

-- Gaby

Re: New file extension

[Diego Novillo]

On Sat, Jul 27, 2013 at 9:42 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> Hi,
>
> I would like to suggest that new implementation files have
> the '.cc' extension, unless they are meant to be processed
> with a C compiler.  (I am not proposing wholesale renaming.)

Agreed.


Diego.

Re: New file extension

[Marek Polacek]

On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote:
> Hi,
> 
> I would like to suggest that new implementation files have
> the '.cc' extension, unless they are meant to be processed
> with a C compiler.  (I am not proposing wholesale renaming.)

Oh, I suppose this applies to ubsan, e.g.  (Haven't commited
it to trunk yet, but so far the files still have the '.c'
extension.)  Will rename it then, though I like '.c' more ;).

	Marek

Re: New file extension

[Gabriel Dos Reis]

On Mon, Jul 29, 2013 at 11:11 AM, Marek Polacek <polacek@redhat.com> wrote:
> On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote:
>> Hi,
>>
>> I would like to suggest that new implementation files have
>> the '.cc' extension, unless they are meant to be processed
>> with a C compiler.  (I am not proposing wholesale renaming.)
>
> Oh, I suppose this applies to ubsan,

yes. :-)

-- Gaby

Re: New file extension

[Martin Jambor]

On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote:
> Hi,
> 
> I would like to suggest that new implementation files have
> the '.cc' extension, unless they are meant to be processed
> with a C compiler.  (I am not proposing wholesale renaming.)
> 

I do not care very much but I disagree.  Having some files with .c
suffix and some with .cc suffix would imply some sort of difference
where there is going to be none.  Much more confusing than C++
compiled .c files, especially to newcomers, I suppose... and I though
we cared about them, that's the reason why I'm writing this email.  I
will not be surprised by this myself, so I can live with it.

Martin

Re: New file extension

[Marek Polacek]

On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> I do not care very much but I disagree.  Having some files with .c
> suffix and some with .cc suffix would imply some sort of difference
> where there is going to be none.

Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
have 362 .c files and 0 .cc files, so every new .cc file will step out
of line...  That might be pain for people who are used to do
'grep foo gcc/*.c' and suchlike.

	Marek

Re: New file extension

[Diego Novillo]

On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
> On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
>> I do not care very much but I disagree.  Having some files with .c
>> suffix and some with .cc suffix would imply some sort of difference
>> where there is going to be none.
>
> Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> have 362 .c files and 0 .cc files, so every new .cc file will step out
> of line...  That might be pain for people who are used to do
> 'grep foo gcc/*.c' and suchlike.

Any issues with doing a mass rename then?


Diego.

Re: New file extension

[Basile Starynkevitch]

On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree.  Having some files with .c
> >> suffix and some with .cc suffix would imply some sort of difference
> >> where there is going to be none.
> >
> > Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> > have 362 .c files and 0 .cc files, so every new .cc file will step out
> > of line...  That might be pain for people who are used to do
> > 'grep foo gcc/*.c' and suchlike.
> 
> Any issues with doing a mass rename then?


I think it is a good idea now (except perhaps for the very few source files
which could still be compiled by a plain C, not C++, compiler; maybe we 
don't have anymore them...).

FWIW, when compiling GCC trunk with Clang3.4 (i.e. on Debian/Sid+Experimental) 
I am getting warnings about *.c being a C++ file.

And I think newbies are distracted also by .c files being in C++ (not to mention
emacs or other editors being possibly confused).

So I am in favor of a massive renaming. (But please do it in one single huge svn commit).

Cheers
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: New file extension

[Joseph S. Myers]

On Tue, 30 Jul 2013, Basile Starynkevitch wrote:

> I think it is a good idea now (except perhaps for the very few source files
> which could still be compiled by a plain C, not C++, compiler; maybe we 
> don't have anymore them...).

gcov-io.c is C code used for both host and target (one of the remaining 
bits of target library source not moved out of the gcc/ directory because 
of the complications of the dual way it's used), but it's used for the 
host (and built as C++ when so used) via #include in other .c files rather 
than being built directly.

Various Ada runtime library files are also .c under gcc/ada - in general, 
I'm not sure which .c files there are used as C, C++ or both, and which 
are used for host, target or both; that would require careful 
investigation for any renaming.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: New file extension

[Marek Polacek]

On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree.  Having some files with .c
> >> suffix and some with .cc suffix would imply some sort of difference
> >> where there is going to be none.
> >
> > Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> > have 362 .c files and 0 .cc files, so every new .cc file will step out
> > of line...  That might be pain for people who are used to do
> > 'grep foo gcc/*.c' and suchlike.
> 
> Any issues with doing a mass rename then?

If various svn/git blame/log's would work, then I'm fine with it.
It's been discussed on gcc@ at some point; I don't remember any
major (dis)advantages.

Ok, I'll rename my new .c files to .cc.

	Marek

Re: New file extension

[Martin Jambor]

Hi,

On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree.  Having some files with .c
> >> suffix and some with .cc suffix would imply some sort of difference
> >> where there is going to be none.
> >
> > Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> > have 362 .c files and 0 .cc files, so every new .cc file will step out
> > of line...  That might be pain for people who are used to do
> > 'grep foo gcc/*.c' and suchlike.
> 
> Any issues with doing a mass rename then?
> 

Well, IIRC mostly worries about history.  SVN claims to be able to
track history of renamed files but I use the git mirror now and I
wonder what the history would show there.  I would consider it very
unfortunate if 'git blame' did not show the .c era history of the
renamed files.  But maybe it would just work.

I think that proponents of this idea should make some experiments
along these lines to estimate the cost.  OTOH, I think the time can be
spent better (and that is also the reason why I will not fight about
this beyond writing this message).

As far as newbies are concerned, I think that grasping that .c files
are C++ files is one of the easy things to learn about GCC compared to
other necessary knowledge (which is something we should work on).

If the problem is that your emacs opens gcc files in C mode instead of
C++, add this to your .emacs file:

(add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode))

Even after a rename you would have to do something like that for the
.h files anyway.

Thanks,

Martin

Re: New file extension

[Basile Starynkevitch]

On Tue, Jul 30, 2013 at 11:51:35AM +0000, Joseph S. Myers wrote:
> On Tue, 30 Jul 2013, Basile Starynkevitch wrote:
> 
> > I think it is a good idea now (except perhaps for the very few source files
> > which could still be compiled by a plain C, not C++, compiler; maybe we 
> > don't have anymore them...).
> 
> gcov-io.c is C code used for both host and target (one of the remaining 
> bits of target library source not moved out of the gcc/ directory because 
> of the complications of the dual way it's used), but it's used for the 
> host (and built as C++ when so used) via #include in other .c files rather 
> than being built directly.
> 
> Various Ada runtime library files are also .c under gcc/ada - in general, 
> I'm not sure which .c files there are used as C, C++ or both, and which 
> are used for host, target or both; that would require careful 
> investigation for any renaming.

Ok. Then we could at leat rename to *.cc those files which are obviously directly
using C++ features (e.g. the class or virtual C++ keywords).

Maybe these files should before renaming have

   #ifndef __cplusplus
   #error should be compiled as C++ code
   #endif

??

Cheers

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: New file extension

[Eric Botcazou]

> Various Ada runtime library files are also .c under gcc/ada - in general,
> I'm not sure which .c files there are used as C, C++ or both, and which
> are used for host, target or both; that would require careful
> investigation for any renaming.

The C files directly under ada/ cannot be renamed since they are meant to be 
compiled by the C compiler; only the ones under ada/gcc-interface can.

-- 
Eric Botcazou

Re: New file extension

[Andrew MacLeod]

On 07/30/2013 08:27 AM, Marek Polacek wrote:
> On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
>> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
>>> On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
>>>> I do not care very much but I disagree.  Having some files with .c
>>>> suffix and some with .cc suffix would imply some sort of difference
>>>> where there is going to be none.
>>> Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
>>> have 362 .c files and 0 .cc files, so every new .cc file will step out
>>> of line...  That might be pain for people who are used to do
>>> 'grep foo gcc/*.c' and suchlike.
>> Any issues with doing a mass rename then?
I'd suggest waiting for a mass rename until the next stage 1... (or 
stage 0.9 :-) I will want to mass rename a lot of the files (ie, a lot 
of tree-* will lose the tree- prefix), and I think we'll be moving 
directory structures around as well... and some include files will be 
split up... etc. etc.    Seems like a logical time to change extensions too.

My point is, why go through the pain of changing a bunch of files now 
when we are probably going to do it again within a year.

Andrew

Re: New file extension

[Marek Polacek]

On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote:
> On 07/30/2013 08:27 AM, Marek Polacek wrote:
> >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
> >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >>>>I do not care very much but I disagree.  Having some files with .c
> >>>>suffix and some with .cc suffix would imply some sort of difference
> >>>>where there is going to be none.
> >>>Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> >>>have 362 .c files and 0 .cc files, so every new .cc file will step out
> >>>of line...  That might be pain for people who are used to do
> >>>'grep foo gcc/*.c' and suchlike.
> >>Any issues with doing a mass rename then?
> I'd suggest waiting for a mass rename until the next stage 1... (or
> stage 0.9 :-) I will want to mass rename a lot of the files (ie, a
> lot of tree-* will lose the tree- prefix), and I think we'll be
> moving directory structures around as well... and some include files
> will be split up... etc. etc.    Seems like a logical time to change
> extensions too.
> 
> My point is, why go through the pain of changing a bunch of files
> now when we are probably going to do it again within a year.

On second thought, yes, waiting for mass rename sounds better than to
add one .cc file...

	Marek

Re: New file extension

[Gabriel Dos Reis]

On Mon, Jul 29, 2013 at 3:08 PM, Martin Jambor <mjambor@suse.cz> wrote:
> On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote:
>> Hi,
>>
>> I would like to suggest that new implementation files have
>> the '.cc' extension, unless they are meant to be processed
>> with a C compiler.  (I am not proposing wholesale renaming.)
>>
>
> I do not care very much but I disagree.  Having some files with .c
> suffix and some with .cc suffix would imply some sort of difference
> where there is going to be none.  Much more confusing than C++
> compiled .c files, especially to newcomers, I suppose... and I though
> we cared about them, that's the reason why I'm writing this email.  I
> will not be surprised by this myself, so I can live with it.
>
> Martin

We do care about newcomers, but with all these new projects
for refactoring, rewrites going on, I think you are worrying about
things that may start "big" now but will be vanishing as the
GCC project lives on.

-- Gaby

Re: New file extension

[Gabriel Dos Reis]

On Tue, Jul 30, 2013 at 6:13 AM, Diego Novillo <dnovillo@google.com> wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
>> On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
>>> I do not care very much but I disagree.  Having some files with .c
>>> suffix and some with .cc suffix would imply some sort of difference
>>> where there is going to be none.
>>
>> Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
>> have 362 .c files and 0 .cc files, so every new .cc file will step out
>> of line...  That might be pain for people who are used to do
>> 'grep foo gcc/*.c' and suchlike.
>
> Any issues with doing a mass rename then?

I didn't want to open of the can of worm where would find
any reason to make this happen.  There might be genuine
concerns with people doing work on branches.

-- Gaby

Re: New file extension

[Gabriel Dos Reis]

On Tue, Jul 30, 2013 at 4:04 AM, Marek Polacek <polacek@redhat.com> wrote:
> On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
>> I do not care very much but I disagree.  Having some files with .c
>> suffix and some with .cc suffix would imply some sort of difference
>> where there is going to be none.
>
> Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> have 362 .c files and 0 .cc files, so every new .cc file will step out
> of line...

Any thing *new* steps out of line for someone.
Putting C++ programs in .c file is out of line for most people,
including the newcomers that people worry about.

For many tools, including editors, .c is a C file, not a C++ file,
so you don't get the benefit of working with a C++ program.

> That might be pain for people who are used to do
> 'grep foo gcc/*.c' and suchlike.
>
>         Marek

Re: New file extension

[Gabriel Dos Reis]

On Tue, Jul 30, 2013 at 6:51 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 30 Jul 2013, Basile Starynkevitch wrote:
>
>> I think it is a good idea now (except perhaps for the very few source files
>> which could still be compiled by a plain C, not C++, compiler; maybe we
>> don't have anymore them...).
>
> gcov-io.c is C code used for both host and target (one of the remaining
> bits of target library source not moved out of the gcc/ directory because
> of the complications of the dual way it's used), but it's used for the
> host (and built as C++ when so used) via #include in other .c files rather
> than being built directly.

This is a good example of what I meant originally by "unless they are
meant to be processed by a C compiler."

> Various Ada runtime library files are also .c under gcc/ada - in general,
> I'm not sure which .c files there are used as C, C++ or both, and which
> are used for host, target or both; that would require careful
> investigation for any renaming.

Indeed.

-- Gaby

Re: New file extension

[Gabriel Dos Reis]

On Tue, Jul 30, 2013 at 7:28 AM, Martin Jambor <mjambor@suse.cz> wrote:

> As far as newbies are concerned, I think that grasping that .c files
> are C++ files is one of the easy things to learn about GCC compared to
> other necessary knowledge (which is something we should work on).

One more oddities compared to standard practice.

> If the problem is that your emacs opens gcc files in C mode instead of
> C++, add this to your .emacs file:
>
> (add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode))

More oddities: we assume Emacs, and we want people to add those things.
Are we sure we are worrying about newcomers, or just fighting to preserve
the way things used to be 20 years?

Re: New file extension

[Gabriel Dos Reis]

On Tue, Jul 30, 2013 at 7:42 AM, Marek Polacek <polacek@redhat.com> wrote:
> On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote:
>> On 07/30/2013 08:27 AM, Marek Polacek wrote:
>> >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
>> >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek <polacek@redhat.com> wrote:
>> >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
>> >>>>I do not care very much but I disagree.  Having some files with .c
>> >>>>suffix and some with .cc suffix would imply some sort of difference
>> >>>>where there is going to be none.
>> >>>Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
>> >>>have 362 .c files and 0 .cc files, so every new .cc file will step out
>> >>>of line...  That might be pain for people who are used to do
>> >>>'grep foo gcc/*.c' and suchlike.
>> >>Any issues with doing a mass rename then?
>> I'd suggest waiting for a mass rename until the next stage 1... (or
>> stage 0.9 :-) I will want to mass rename a lot of the files (ie, a
>> lot of tree-* will lose the tree- prefix), and I think we'll be
>> moving directory structures around as well... and some include files
>> will be split up... etc. etc.    Seems like a logical time to change
>> extensions too.
>>
>> My point is, why go through the pain of changing a bunch of files
>> now when we are probably going to do it again within a year.
>
> On second thought, yes, waiting for mass rename sounds better than to
> add one .cc file...
>
>         Marek

I am skeptical we would be able to implement mass renaming.

-- Gaby

Re: New file extension

[Martin Jambor]

Hi,

On Tue, Jul 30, 2013 at 11:07:52AM -0500, Gabriel Dos Reis wrote:
> On Tue, Jul 30, 2013 at 7:28 AM, Martin Jambor <mjambor@suse.cz> wrote:
> 
> > As far as newbies are concerned, I think that grasping that .c files
> > are C++ files is one of the easy things to learn about GCC compared to
> > other necessary knowledge (which is something we should work on).
> 
> One more oddities compared to standard practice.
> 
> > If the problem is that your emacs opens gcc files in C mode instead of
> > C++, add this to your .emacs file:
> >
> > (add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode))
> 
> More oddities: we assume Emacs, and we want people to add those things.
> Are we sure we are worrying about newcomers, or just fighting to preserve
> the way things used to be 20 years?

I am quite sure.  You removed part of my email where I said I would
not mind mass renaming at all if git history was still easily usable.
This is not because I am some sort of crazy conservative, it is
because I use the history very often and I believe I am not alone.

Moreover, after reading Andrew's email in which he outlined a mass
renaming as a part of re-architecting gcc, I believe that waiting for
that to happen and having it happen is the best course of action (even
regardless of inconveniences with git history because that is not
going to be renaming for the sake of renaming but a substantial
change, worth doing nevertheless, or at least I hope so).

In the meantime, people can reconfigure their editor as I do with
emacs.

I still think that mixing C++ .c files and .cc files is silly and more
confusing than what we have now.  However, I can live with it.

As far as newcomers are concerned, I have joined GCC only about 6
years ago so I am still quite new and still remember my earliest days.
From my experience, the real obstacles are the tough issues to
overcome (like when you have an ICE in expr.c and there is no way you
can understand what is even going on there, let alone why it ICEs),
certainly not a number of small oddities.  If we really want to help
newcomers, we have to concentrate on the difficult stuff.  The simple
things usually do not really matter.

Furthermore, if we do a svn rename here and there, _mechanically_ turn
a struct into a class or a macro into a template (you noted I stressed
the word mechanically, right?) or remove some other small oddity at
the expense of making life of core gcc developers more difficult, the
newcomers will not even notice and the overall outcome will be
negative.  This is not trying to keep things as they were 20 years
ago, this is saying we should only make changes that make sense.  And
personally, I hope I will not only welcome such changes, but also be
able to help with them.

Martin

Re: New file extension

[Steinar Bang]

>>>>> Martin Jambor <mjambor@suse.cz>:

> Well, IIRC mostly worries about history.  SVN claims to be able to
> track history of renamed files but I use the git mirror now and I
> wonder what the history would show there.  I would consider it very
> unfortunate if 'git blame' did not show the .c era history of the
> renamed files.  But maybe it would just work.

It depends on how the rename if done.  If a file is added that has the
exact same SHA1 hash as a file with a different path, then git assumes
that the new file is a copy of the other file, and blame and the log
history can be made to follow the history beyond the copy.  Actually
"git blame" always follow the history across renames, and "git log"
needs the "--follow" option, or a config setting, to do so.

I have no idea what git-svn (or whatever) will do when it comes to an
svn rename, but it would make sense if it replicated it by a commit that
does a git rm of the file in the old location, and a git add of the file
in the new location.

If the svn rename also changes the renamed file, then things get
trickier... git-svn would have to split that commit into two.