Hi,
The coding conventions for gcc 3.4 and up say to no longer use k&r style definitions. Is gpc going to follow suit? I.e. Will patches to remove PARAMS and switch away from k&r style definitions be accepted?
James A. Morrison wrote:
The coding conventions for gcc 3.4 and up say to no longer use k&r style definitions. Is gpc going to follow suit?
Eventually yes.
I.e. Will patches to remove PARAMS and switch away from k&r style definitions be accepted?
I think such a patch is not really necessary. I can probably do this more or less automated, which is probably easier than syncing a patch with other ongoing changes.
What's needed is rather a patch to the Makefiles etc. of the older backends to suppress such warnings etc. I don't suppose you'd like to do it, but I can probably look at it rather soon ...
Frank
On Sun, 13 Mar 2005 18:29:02 +0100, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
James A. Morrison wrote:
The coding conventions for gcc 3.4 and up say to no longer use k&r style definitions. Is gpc going to follow suit?
Eventually yes.
I.e. Will patches to remove PARAMS and switch away from k&r style definitions be accepted?
I think such a patch is not really necessary. I can probably do this more or less automated, which is probably easier than syncing a patch with other ongoing changes.
What's needed is rather a patch to the Makefiles etc. of the older backends to suppress such warnings etc. I don't suppose you'd like to do it, but I can probably look at it rather soon ...
The oldest backend I have to test with is gcc 3.3, so I'm not sure what anything older than that expects.
Frank
On Sun, 13 Mar 2005 18:29:02 +0100, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
James A. Morrison wrote:
The coding conventions for gcc 3.4 and up say to no longer use k&r style definitions. Is gpc going to follow suit?
Eventually yes.
I.e. Will patches to remove PARAMS and switch away from k&r style definitions be accepted?
I think such a patch is not really necessary. I can probably do this more or less automated, which is probably easier than syncing a patch with other ongoing changes.
What's needed is rather a patch to the Makefiles etc. of the older backends to suppress such warnings etc. I don't suppose you'd like to do it, but I can probably look at it rather soon ...
Frank
Attached is a patch that unconditionally adds -Wno-traditional to Make-lang.in. It seems to work with gcc 3.3
James A. Morrison wrote:
On Sun, 13 Mar 2005 18:29:02 +0100, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
James A. Morrison wrote:
The coding conventions for gcc 3.4 and up say to no longer use k&r style definitions. Is gpc going to follow suit?
Eventually yes.
I.e. Will patches to remove PARAMS and switch away from k&r style definitions be accepted?
I think such a patch is not really necessary. I can probably do this more or less automated, which is probably easier than syncing a patch with other ongoing changes.
What's needed is rather a patch to the Makefiles etc. of the older backends to suppress such warnings etc. I don't suppose you'd like to do it, but I can probably look at it rather soon ...
Attached is a patch that unconditionally adds -Wno-traditional to Make-lang.in. It seems to work with gcc 3.3
I've also added it for gcc-2.x, seems to work.
OK, I'm removing all K&R style definitions and `PARAMS'. (I'll just finish fixing some urgent issues, then I'll put out a new tarball, including this change.)
BTW, for new style declarations, it's possible to omit the forward declaration if a static routine is declared before its first use. Should/can we do this, or does GCC want forward declarations for all static functions?
Frank
On Mon, 14 Mar 2005 12:13:47 +0100, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
James A. Morrison wrote:
On Sun, 13 Mar 2005 18:29:02 +0100, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
James A. Morrison wrote:
The coding conventions for gcc 3.4 and up say to no longer use k&r style definitions. Is gpc going to follow suit?
Eventually yes.
I.e. Will patches to remove PARAMS and switch away from k&r style definitions be accepted?
I think such a patch is not really necessary. I can probably do this more or less automated, which is probably easier than syncing a patch with other ongoing changes.
What's needed is rather a patch to the Makefiles etc. of the older backends to suppress such warnings etc. I don't suppose you'd like to do it, but I can probably look at it rather soon ...
Attached is a patch that unconditionally adds -Wno-traditional to Make-lang.in. It seems to work with gcc 3.3
I've also added it for gcc-2.x, seems to work.
OK, I'm removing all K&R style definitions and `PARAMS'. (I'll just finish fixing some urgent issues, then I'll put out a new tarball, including this change.)
BTW, for new style declarations, it's possible to omit the forward declaration if a static routine is declared before its first use. Should/can we do this, or does GCC want forward declarations for all static functions?
Frank
GCC wants prototypes for all functions.