FreeBSD Port: pornview-0.2.0.p.1

[Erik Trulsson]

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 at student.uu.se