X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org To: cygwin@cygwin.com From: Diego Biurrun Subject: Re: llrint implementation in Cygwin Date: Mon, 01 Oct 2007 19:36:22 +0200 Lines: 59 Message-ID: References: <46F6C151.3070301@computer.org> <46FEC886.7020007@cwilson.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8b) Gecko/20050217 In-Reply-To: <46FEC886.7020007@cwilson.fastmail.fm> X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Charles Wilson wrote: > Diego Biurrun wrote: > >> llrint is required, so I guess Cygwin compilation will indeed be >> broken for a while. We don't add OS-specific workarounds to FFmpeg. > > I call shenanigans. Next time you call shenanigans, get your facts straight first please. I never claimed that we do not *have* OS-specific workarounds, I said we do not *add* them. > The libavcodec directory has entirely separate > subdirs for different processors -- platform specificity is BUILT IN to > the ffmpeg source tree. Nonsense. These are assembler optimizations for speed-critical functions (and the reason why you can watch movies without GHz CPUs). These are, by their very nature, processor-specific, but they are not workarounds. Nothing could be further from the truth. > That file ALSO contains a > half-dozen implementations of read_time depending on which > microprocessor architecture is in use. What does this have to do with a workaround? read_time is internally used in some benchmarking macros, it is not an OS function. > Oh, and lookee here, in the same file: > > #ifndef HAVE_LRINTF > /* XXX: add ISOC specific test to avoid specific BSD testing. */ > /* better than nothing implementation. */ > /* btw, rintf() is existing on fbsd too -- alex */ > static av_always_inline long int lrintf(float x) > { > return (int)(rint(x)); > } > #endif /* HAVE_LRINTF */ Good catch, this is cruft from ages ago. I will look into nuking this very soon. > So, we have: > architecture-specific workarounds > compiler-specific workarounds > OS-specific workarounds > AND capability-specific (!HAVE_FOO) workarounds > > All god's chillins gots workaround code. "We don't add OS-specific > workarounds", indeed... So all in all you have refuted some points I never made, while bungling some of the research used to substantiate your claims. What is the point you are trying to prove here? best regards Diego -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/