public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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;
		/* ... */
	}


             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).