llrint implementation in Cygwin

[Diego Biurrun]

Charles Wilson wrote:
> Diego Biurrun wrote:
> 
>> 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.
> 
> That's a verrrry fine distinction and was not at all clear from the 
> foregoing conversation.

Maybe I was not terribly clear nor explicit.  That does not preclude you 
from stating your points a little more, umm, defensively, does it?

>>  > 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.
> 
> It's an example of special purpose (blocks of) code, where a given block 
> is compiled only under particular circumstances -- e.g. for a specific 
> target cpu -- in pursuit of a particular goal.  In this case: speed. 
> Control flow (whether a particular file or block of code is actually 
> compiled for a given target) is determined by...for lack of a better 
> term, "makefile magic".

No, I'm not letting you off the hook here, you are still talking nonsense.

>>  > 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.
> 
> It's an exampleof special purpose (blocks of) code, where a given block 
> is compiled only under particular circumstances -- e.g. for a specific 
> target cpu -- in pursuit of a particular goal.  In this case: high res 
> benchmarking. Control flow (whether a particular file or block of code 
> is actually compiled for a given target) is determined by...using the 
> earlier nomenclature, "ifdef magic".

.. and nonsense again ..

What are you going to claim next?  That something like

if ( condition )
     block of code
else
     block of alternative code

is an example of special purpose (blocks of) code where given block is 
run only under particular circumstances in pursuit of a particular goal 
using "control flow magic"?

>>> 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, I find an example of EXACTLY the sort of feature-dependent 
> workaround under discussion, and your response is "no, that's not a 
> valid example...and if it is, we'll get rid of it?"

You have an interesting way of twisting words.  I say "good catch" and 
you translate this to "no, that's not a valid example".

It's doubly interesting that I admit you are right and you turn this 
around into me being in denial while at the same time you are in denial 
about the points where I proved you wrong.

> Look, the point is: there are many platforms out there that do not 
> support the entire panoply of C99 functions. Or even all POSIX (1b? 1c? 
> 1e? 2?) functions.

Yes.  And if every program out there tries to be "portable" to those 
platforms by adding workarounds to their codebase we will soon have 
terabytes of cruft and bugs all over the place.

Then again, if just one of them goes to the length of patching upstream 
instead of hacking their code, all those programs will suddenly work on 
that platform.

Short term pain, long term gain, it boils down to nothing more than that...

 > If the FFMpeg team cares about portability, the
> correct answer is not to climb upon a high horse, declaim "we do not 
> [use|add] platform-specific workarounds" and deliberately release code 
> that is /not/ portable to the disdained platform -- and then blame that 
> platform for not updating their runtime library according to /your/ 
> project's release schedule. "Well, cygwin will just have to be broken"

You are (again) putting words into my mouth and twisting what I said.

I never
- expressed disdain for Cygwin nor
- blamed Cygwin for not updating their runtime library nor
- forced our release schedule on anybody.

I merely enquired whether
- an implementation of llrint was in the works and
- when it would hit mainstream Cygwin.

This was done so that I could add an appropriate comment into the 
release notes about the status of Cygwin support.  Heck, if the answer 
had been something along the lines of "We'll have it next month" or 
similar, we might even have delayed *our* release to accomodate this. 
Now if somebody inquires about the status of Cygwin compilation I can 
advise them to either (in order of preference)

- patch newlib or
- upgrade their gcc somehow or
- wait for the official gcc upgrade in Cygwin or
- patch their private copy of FFmpeg.

> If you do /not/ care about portability, then the response above is 
> perfectly fine.

We do care about portability, that's why we make an effort to fix things 
in the appropriate place - in this case Cygwin itself - to the benefit 
of everybody and not add quick hacks to our code in order to paper over 
the problem.

>> 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?
> 
> No, you missed the point of the three examples. They demonstrate a 
> plethora of special-purpose code: whether (the control flow determining 
> if a particular hunk of code is compiled) is in the Makefile magic 
> (build the i386 subdir, don't build the ppc subdir, etc) or is in the 
> ifdef magic (#ifdef HAVE_I386_CPU, etc) is immaterial.

Nonsense, this is not immaterial.  Of course special-purpose code exists 
and of course there are places where special purpose code is 
appropriate.  You are, however, drawing wrong conclusions from the 
existence of certain forms of special-purpose code.  The appropriateness 
of such code under one set of circumstances has no bearing at all on 
other sets of circumstances.

> It was just disappointing to see a simple replacement function -- no 
> different in principle than any of the three examples I provided, and 
> practically identical to the last example, rejected with a blase' "we 
> don't add platform-specific workarounds -- cygwin will just have to be 
> broken". WTH?

You are subtly twisting my words again.  I never said that "cygwin will 
have to be broken", I said that "cygwin compilation will indeed be 
broken for a while", meaning that it will mend itself with the next gcc 
upgrade but remain broken until then.

My intentions when starting this thread were nothing but constructive, I 
never intended to slander Cygwin (nor do I think I did).  Apologies to 
all innocent bystanders for the flamage this is degenerating into.

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/