Date: Sat, 17 May 2003 15:52:17 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: Jonathan Belson <jon@witchspace.com> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: FreeBSD Port: pornview-0.2.0.p.1 Message-ID: <20030517135217.GA88537@falcon.midgard.homeip.net> In-Reply-To: <3EC63B78.6010203@witchspace.com> References: <3EC53C6C.1040904@witchspace.com> <20030517121908.GA67369@rot13.obsecurity.org> <3EC62CC2.6090209@witchspace.com> <20030517130549.GA44928@falcon.midgard.homeip.net> <3EC63B78.6010203@witchspace.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 17, 2003 at 02:39:04PM +0100, Jonathan Belson wrote:
> Erik Trulsson wrote:
> >That part of the structure is not the problem. The next part of this
> >structure is the problem.
> >
> > gchar stdout[GTK_MPLAYER_BUF_SIZE];
> > gint stdout_size;
> > gchar stderr[GTK_MPLAYER_BUF_SIZE];
> > gint stderr_size;
>
> True.
>
> >Not legitimate. The C standard itself says that stdin/stdout/stderr are
> >supposed to be macros and therefore this behaviour is expected
>
> Interesting...do you have a reference for this? Section 7.9.1 of
> the ANSI C spec says that stdin/stdout/stderr are expressions of
> type 'pointer to FILE', I can't see anything that says they're
> supposed to be macros.
>From (a draft version of) the C99 standard:
7.19.1
[#1] The header <stdio.h> declares three types, several
macros, and many functions for performing input and output.
....
[#3] The macros are [...]
...
stderr
stdin
stdout
which are expressions of type `pointer to FILE'' that point
to the FILE objects associated, respectively, with the
standard error, input, and output streams.
Besides, the only way I can think of to have stdin/stdout/stderr
available as expressions but not #define them is to have them as just
plain variables, and if that was the only option available I am sure
the standards committee would have written that. So even with the wording
you give they *could* be macros, but might not necessarily have been.
>
> > The bug is in the application, not in FreeBSD, so, unfair or not, it
> > isn't FreeBSD that should be changed.
>
> I don't remember anyone stating that FreeBSD should be changed...
Not explicitly no, but if the pornview code was OK there wouldn't have
been many other options left.
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030517135217.GA88537>