[Ffmpeg-devel] FFMPEG RTSP for Windows
Rich Felker
dalias
Fri Mar 31 00:30:43 CEST 2006
On Thu, Mar 30, 2006 at 02:44:20PM -0600, Michael A. Kohn wrote:
> If you're referring to this test:
>
> main() { sleep(500); }
>
> I didn't do that test on MSVC. That won't even compile on MSVC since
> sleep isn't defined.
Thanks, you've just proved to us that MSVC is broken. This code is
totally legitimate (although deprecated in C99) even without sleep
being defined.
> > > > +/* I'm sure the next two lines are evil in some way, but I'm not sure
> > > > + how else to do that right now */
> > >
> > > the way it is right now does not compile. i was hoping someone could have
> > > been nice enough to explain why instead of you coming around and insulting
> > > me... i'm sorry if what i did is so horrible, but that was the only way
> > > that was going to compile..
> >
> > Well if there's buggy code you need to fix it, not pile workarounds on
> > top of it that hide the bugs.
>
> Well, I'm not sure how to take care of random() since it doesn't seem to
> exist in MingW. Do you or anyone else on this mailing list have a good
> suggestion?
Yes, removing it, which I did a few hours ago.
> > Again MSVC is _not supported_. This is intentional due to noncompliant
> > broken things exactly like what you've described here.
>
> I don't use MSVC. I'm not a Windows guy at all, I only program Windows at
> work and when cross compiling my own programs for others to use. I used
> MSDN's documentation every once in a while for looking up function
> prototypes and such since MingW as I understand it is supposed to be the
> GCC compiler working with Microsoft libraries and such.
>
> Anyway, my question is, would you or anyone else like to me make these
> changes and resubmit a patch? or should I just leave this code to myself?
Unless you can make it entirely unobtrusive I doubt it will be very
welcome. In the long term mingw's direct linking to MSVCRT should be
replaced either with a legitimate, correct C library or with wrappers
that provide a minimal degree of correct interfaces/semantics (but not
a whole bloated emulation environment like cygwin). This is a project
in itself of course.
Rich
More information about the ffmpeg-devel
mailing list