From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Fri, 02 Jun 2000 02:42:00 -0000 [thread overview]
Message-ID: <3937816C.E66B9AE0@cygnus.com> (raw)
In-Reply-To: <1000602075018.ZM29997@ocotillo.lan>
Kevin Buettner wrote:
>
> As many of you know, I'm in the midst of purging the use of ``PARAMS''
> in prototyped function declarations from the gdb sources. After this
> activity is concluded, I'd like to begin converting function
> definitions whose parameters are declared using the traditional C
> style to the ISO C prototyped form. I.e, I'd like to convert
> functions of the form
>
> int
> foo (a, b, c)
> int a;
> char *b;
> int *c;
> {
> ...
> }
>
> to
>
> int foo (int a, char *b, int *c)
> {
> ...
> }
(you mean
int
foo (int a, char *b, int *c)
:-)
The obvious thing to note is that by moving to pure ISO-C we eliminate
the type promotion problems. For instance:
void foo (enum e e);
void
foo (e)
enum e e;
{
}
is not well defined and many compilers reject it. Plenty of similar
examples (involving char, short, and the like exist).
It is one less issue that people need to worry about.
The only concern I have is, given the slightly more complex nature of
the script (compared to PARAMS) there is a possibility that the
conversion re-orders or re-types the argument list. With that in mind,
should a pre-cursor to this be to least have prototypes for all
(global?) functions (-Wmissing-prototypes?) or only do the conversion
when there is a prototype visible?
Andrew
PS: You may want to add gdb/*-share to the list of directories to avoid.
next prev parent reply other threads:[~2000-06-02 2:42 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-02 0:50 Kevin Buettner
2000-06-02 2:42 ` Andrew Cagney [this message]
2000-06-03 0:13 ` Kevin Buettner
2000-06-03 0:21 ` Kevin Buettner
2000-06-03 4:52 ` Andrew Cagney
2000-06-02 5:26 ` Mark Kettenis
2000-06-02 8:16 ` Kevin Buettner
2000-06-02 10:44 ` J.T. Conklin
2000-06-03 5:17 ` Andrew Cagney
2000-06-05 11:05 ` J.T. Conklin
2000-06-12 16:30 ` Eric Bachalo
2000-06-12 17:29 ` Andrew Cagney
2000-06-12 18:03 ` Daniel Berlin
2000-06-12 18:15 ` Stan Shebs
2000-06-12 18:23 ` Daniel Berlin
2000-06-12 19:16 ` Anatoly Vorobey
2000-06-12 19:42 ` Daniel Berlin
2000-06-12 18:55 ` Kevin Buettner
2000-06-13 3:34 ` Eli Zaretskii
2000-06-03 4:48 ` Andrew Cagney
2000-06-12 18:10 ` Andrew Cagney
2000-06-12 19:48 ` Kevin Buettner
2000-06-02 8:40 David Taylor
2000-06-02 12:10 ` Kevin Buettner
2000-06-03 3:58 ` Eli Zaretskii
[not found] ` <eliz@delorie.com>
2000-06-03 10:50 ` Kevin Buettner
2000-06-03 11:37 ` Eli Zaretskii
2000-06-03 18:18 ` Andrew Cagney
2000-06-03 15:42 ` Kevin Buettner
2000-06-02 13:11 David Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3937816C.E66B9AE0@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb@sourceware.cygnus.com \
--cc=kevinb@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).