[Ffmpeg-devel] [PATCH] '/nop' illegal for old versions of GAS

Michael Niedermayer michaelni
Mon Aug 7 12:00:48 CEST 2006


On Mon, Aug 07, 2006 at 10:33:31AM +1000, Nigel Pearson wrote:
> On 04/08/2006, at 8:44 PM, Michael Niedermayer wrote:
> >On Fri, Aug 04, 2006 at 11:42:09AM +1000, Nigel Pearson wrote:
> >>	I have spent a lot of time testing various combinations.
> >
> >thats sad, you should have read the c pre processor manual instead
> 	RTFM? You know that's a last resort!
> ...

no, first read the manual then post to a public mailing list
iam really puzzled by the attitude macintel & windows developers

> >the following example shows how to do it, its completely trivial
> >#define idct(oppcode) \
> >    oppcode " arg1 arg2\n\t"
> >#define NOP " # nop"
> >idct(NOP)
> 	Yes, that works, but the macro currently uses #oppcode.
> 	I assumed you wanted to keep the ability
> to pass in an opcode to do rounding?

yes, of course, the code must still work ...

> 	If modifying the macro to remove the rounding ability
> is OK, then this all becomes easy - just comment it out:
> -        #rounder ", %%mm4               \n\t"\
> +        /* #rounder ", %%mm4            \n\t" Add a rounding constant 
> */\

sorry no, i summarize it again
NOP must be a macro defined by #define
the output of the code must not change
the code must be clean, the patch must conform to whats described in our
theres nothing tricky with that its a plain and simple change

you dont seem to know how the c preprocessor works, and you dont seem to
be willing to learn it / read the manual thats fine but then you dont
qualify as contributor, as knowledge of the language or at least will to
read the manuals is required to contribute to a project which is written
in that language, again,
i dont need mac intel support, if someone wants it he has to do the work

also note that if the trolling about macintel continues
(trolling here means repeatly sending patches and proposing things which ive
said already are not ok) then ill ban thouse who send such spam, as it
confuses others into thinking that someone would be working on macintel
support while we are actually just playing with a troll who never intended
to send a useable patch but instead is trying to cause as much work for us
as possible, again the patch submitter must do the work not we, this is true
for every patch. alternatives are not possible for a project of the size of
ffmpeg, we simply cannot rewrite everything people submit

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is

More information about the ffmpeg-devel mailing list