From: H.J. Lu <hjl@lucon.org>
To: egcs@cygnus.com
Subject: Ugly *.def in gcc
Date: Tue, 19 Aug 1997 19:24:42 -0000 [thread overview]
Message-ID: <m0x0u7p-0004ecC@ocean.lucon.org> (raw)
Hi,
Many people object my proposed patch to *.def in gcc. I can
understand it. I hated it when I started working on gcc
prototyping and I still don't like it now.
But after spending days on it, I realized that there was no
better alternative other than expending the current ugly
scheme unless you want to do some massive restructure. Right
now, gcc has
--rtl.h---
#define RTX_CODE enum rtx_code
enum rtx_code {
#define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) ENUM ,
#include "rtl.def"
#undef DEF_RTL_EXPR
LAST_AND_UNUSED_RTX_CODE};
I modified it to
--rtl.h--
#define NEED_enum_rtx_code
#include "rtl.def"
#undef NEED_enum_rtx_code
My change certainly doesn't fix the ugliness. But it makes
prototype work.
--
H.J. Lu (hjl@gnu.ai.mit.edu)
WARNING: multiple messages have this Message-ID
From: Jeffrey A Law <law@hurl.cygnus.com>
To: egcs@cygnus.com
Subject: Re: A prototype patch for tree.h/tree.def/calls.c
Date: Tue, 19 Aug 1997 19:45:02 -0000 [thread overview]
Message-ID: <m0x0u7p-0004ecC@ocean.lucon.org> (raw)
Message-ID: <19970819194502.3P1NM1QPhwk1V84NWDQfaByJMGQNMhpSCXHJLuP5l7U@z> (raw)
In-Reply-To: A prototype patch for tree.h/tree.def/calls.c
In message <m0x0tpx-0004ecC@ocean.lucon.org>you write:
> > But regardless of what other parts of gcc are doing, using "unsigned"
> > in the prototype for xmalloc is wrong and such a change will not be
> > installed.
>
> It makes nosenses when the definion of xmalloc uses unsigned
> and its prototype uses size_t. It is much worse.
Providing a prototype that is blatently wrong will not be accepted.
There's no use argueing about this, an incorrect patch will not
be accepted.
> What is the working alternative? Will it ever be
> implemented. How much will it take to do it? You
> don't have to love something to use it.
The alternative is to get the other stuff installed first, then
analyze the situation later as a group. Your patches for
enum rtx code and enum tree_code will not be accepted without
a review at a later date.
I want this to be a separate issue from the main body of
prototyping patches. Please table this issue until we get
the main body of the prototype patches installed -- continueing
to discuss it only distracts from other stuff that needs to
be addressed at the current time.
> egcs. Besides, there are many prototypes in gcc like it.
> I just happen to like that style when I was working on it.
Sorry to hear that.
> I don't
> feel like to spend my time on it. I don't see why my patch
> should be rejected just because of it.
And I don't have the time or desire to reformat your patches.
If you feel prototyping is important and you want to get it
in soon, then you'll have to do some formatting work.
Jeff
next reply other threads:[~1997-08-19 19:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-08-19 19:24 H.J. Lu [this message]
1997-08-19 19:45 ` A prototype patch for tree.h/tree.def/calls.c Jeffrey A Law
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=m0x0u7p-0004ecC@ocean.lucon.org \
--to=hjl@lucon.org \
--cc=egcs@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).