From: Michael Meissner <meissner@cygnus.com>
To: ghazi@caip.rutgers.edu, schwab@issan.informatik.uni-dortmund.de
Cc: egcs@cygnus.com
Subject: Re: prototyping functions returning an enum, before the enum is defined
Date: Mon, 29 Jun 1998 20:41:00 -0000 [thread overview]
Message-ID: <199806291946.PAA03102@tiktok.cygnus.com> (raw)
| "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
|
| |> Some config/*/*.c files have extern functions returning an
| |> enum of some sort. Eg, function_arg_padding() in sparc.c which
| |> returns an `enum direction'. I'd like to be able to prototype these
| |> in sparc.h, but we don't have the definition of `enum direction' from
| |> expr.h yet.
| |>
| |> Is it legal in both KNR and ANSI C to say:
| |> > extern enum direction function_arg_padding();
| |>
| |> before `enum direction' has been defined?
| |>
| |> What about doing:
| |> > enum direction;
| |> > extern enum direction function_arg_padding();
|
| Both are wrong. ANSI C does not have forward declarations of enum types.
| >From the C9x draft (6.5.2.3 Tags):
|
| [#2] A type specifier of the form
|
| enum identifier
|
| without an enumerator list shall only appear after the type
| it specifies is completed.
|
| I'm pretty sure that this is unchanged from the current standard.
(the current standard is still the 1989/1990 standard).
What I've been doing is declaring the functions as taking an int instead of an
enum, and returning an int:
#ifndef RTX_CODE
struct rtx_def;
#define Rtx struct rtx_def *
#else
#define Rtx rtx
#endif
#ifndef TREE_CODE
union tree_node;
#define Tree union tree_node *
#else
#define Tree tree
#endif
extern int foo_operand PROTO((Rtx, int));
/* ... */
int
foo_operand (op, int_mode)
rtx op;
int int_mode;
{
enum machine_mode mode = (enum machine_mode)int_mode;
/* ... */
}
next reply other threads:[~1998-06-29 20:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-06-29 20:41 Michael Meissner [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-06-28 12:37 Kaveh R. Ghazi
1998-06-29 3:22 ` Andreas Schwab
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=199806291946.PAA03102@tiktok.cygnus.com \
--to=meissner@cygnus.com \
--cc=egcs@cygnus.com \
--cc=ghazi@caip.rutgers.edu \
--cc=schwab@issan.informatik.uni-dortmund.de \
/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).