From: meissner@cygnus.com <meissner@cygnus.com>
To: egcs@cygnus.com
Subject: Re: The prototyping patch for rtl.h/rtl.def
Date: Mon, 18 Aug 1997 03:07:05 -0000 [thread overview]
Message-ID: <199708180317.XAA08185@tweedledumb.cygnus.com> (raw)
In-Reply-To: The prototyping patch for rtl.h/rtl.def
| Is it really safe to use #ifdef BUFSIZE? What's to stop stdio.h from
| doing somethign like
|
| const int BUFSIZE = 1024
|
| ie, is there anything in ANSI that sez BUFSIZE must be a macro?
Yes, it is explicitly required to be a macro. Quoting from a draft of C9X,
since I don't have the standard online:
C9X Draft 10, 1997-06-27, WG14/Nxxx J11/97-xxx
7.12 Input/output <stdio.h>
7.12.1 Introduction
[#1] The header <stdio.h> declares three types, several
macros, and many functions for performing input and output.
[#2] The types declared are size_t (described in 7.1.6);
FILE
which is an object type other than an array type capable of |
recording all the information needed to control a stream,
including its file position indicator, a pointer to its
associated buffer (if any), an error indicator that records
whether a read/write error has occurred, and an end-of-file
indicator that records whether the end of the file has been
reached; and
fpos_t
which is an object type capable of recording all the
information needed to specify uniquely every position within
a file.
[#3] The macros are NULL (described in 7.1.6);
_IOFBF
_IOLBF
_IONBF
which expand to integral constant expressions with distinct
values, suitable for use as the third argument to the
setvbuf function;
BUFSIZ
which expands to an integral constant expression, which is
the size of the buffer used by the setbuf function;
WARNING: multiple messages have this Message-ID
From: Jeffrey A Law <law@hurl.cygnus.com>
To: egcs@cygnus.com
Subject: Re: The prototyping patch for rtl.h/rtl.def
Date: Mon, 18 Aug 1997 05:12:54 -0000 [thread overview]
Message-ID: <199708180317.XAA08185@tweedledumb.cygnus.com> (raw)
Message-ID: <19970818051254.Tj-c4ceGO7f4x8xN_v8GJDqk7ogStExxJsApHH_Lfr0@z> (raw)
In-Reply-To: The prototyping patch for rtl.h/rtl.def
In message <199708180317.XAA08185@tweedledumb.cygnus.com>you write:
> | Is it really safe to use #ifdef BUFSIZE? What's to stop stdio.h from
> | doing somethign like
> |
> | const int BUFSIZE = 1024
> |
> | ie, is there anything in ANSI that sez BUFSIZE must be a macro?
>
> Yes, it is explicitly required to be a macro. Quoting from a draft of C9X,
> since I don't have the standard online:
Good 'nuff. I guess conditionalizing the prototype on the existence of
BUFSIZE is the best way to go.
Jeff
next reply other threads:[~1997-08-18 3:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-08-18 3:07 meissner [this message]
1997-08-18 5:12 ` Jeffrey A Law
-- strict thread matches above, loose matches on Subject: below --
1997-08-18 2:56 meissner
1997-08-18 3:07 ` Jeffrey A Law
1997-08-18 1:03 H.J. Lu
1997-08-18 2:56 ` 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=199708180317.XAA08185@tweedledumb.cygnus.com \
--to=meissner@cygnus.com \
--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).