public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: egcs@cygnus.com
Subject: Re: prototyping functions returning an enum, before the enum is defined
Date: Mon, 29 Jun 1998 03:22:00 -0000	[thread overview]
Message-ID: <vyzzpewtw3v.fsf@issan.informatik.uni-dortmund.de> (raw)
In-Reply-To: <199806281937.PAA00634@caip.rutgers.edu>

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

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

  reply	other threads:[~1998-06-29  3:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-28 12:37 Kaveh R. Ghazi
1998-06-29  3:22 ` Andreas Schwab [this message]
1998-06-29 20:41 Michael Meissner

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=vyzzpewtw3v.fsf@issan.informatik.uni-dortmund.de \
    --to=schwab@issan.informatik.uni-dortmund.de \
    --cc=egcs@cygnus.com \
    --cc=ghazi@caip.rutgers.edu \
    /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).