Still problems with tap_rtp.c.... Undefined functions _open, _close, write,
and read on Windows based OS. See below... Any ideas?
On Thu, Mar 06, 2003 at 04:48:47PM -0700, Greg Morris wrote:
> That
did the trick on that one...
OK, I've checked in a change to precede all
the error enums with
TAP_RTP_, to avoid name collisions.
> Now I'm
almost thru the code... At
> least down to line 1683 when I encounter
hopefully the last error...
>
> tap_rtp.c
>
tap_rtp.c(1683) : error C2466: cannot allocate an array of constant
> size
0
Yup, you can't, in any *sane* compiler.
Unfortunately, it
appears that, in this case, GCC is not sane. OK, I
can see value of
their hack for allowing zero-length arrays:
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/Zero-Length.html#Zero%20Lengthas
the last member of a structure, if the structure is really a
fixed-length
header followed by a variable amount of data. (However, I
don't *use*
that hack, as it's non-portable, and you *can* make it work
with a
one-element array - you just have to do a little more work to
compute the
total length of a structure with N bytes of data.)
But allowing an array
*outside* a structure to be zero length (or, for
that matter, allowing a
zero-length array to be the *only* member of a
structure), just seems stoopid
to me.
It's definitely a bug in tap_rtp.c, given that the code later
assigns a
value to the non-existent first member of that array.
I've
also checked in a change to make it a 1-element array, rather than
a
0-element array.
Try removing gtk/tap_rtp.c and doing a "cvs update"
after a 10-minute or
so delay, to allow the change to propagate to the
anonymous CVS tree -
you should get version 1.4 of gtk/tap_rtp.c (if not,
wait some more time
and try again; lather, rinse,
repeat).
