[MPlayer-cvslog] r27240 - trunk/configure

[Michael Niedermayer]

On Mon, Jul 14, 2008 at 10:45:58AM +0200, Diego Biurrun wrote:
> On Mon, Jul 14, 2008 at 02:36:59AM +0200, Michael Niedermayer wrote:
> > On Sun, Jul 13, 2008 at 12:54:37PM +0200, Reimar Döffinger wrote:
> > > On Sun, Jul 13, 2008 at 12:49:16PM +0200, Diego Biurrun wrote:
> > > > > Could you please post a few of the warnings you where trying to fix. There
> > > > > may be a more correct and clean way to get rid of them.
> > > > 
> > > > Warnings like the following, there was a handful of them:
> > > > 
> > > > libmpcodecs/ad_libvorbis.c: In function 'read_vorbis_comment':
> > > > libmpcodecs/ad_libvorbis.c:48: warning: implicit declaration of function 'vsscanf'
> > > 
> > > Well, at least my man page suggests these solutions to that:
> > > "_XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99"
> > > at least strictly speaking, -std=gnu99 is not among the recommended
> > > solutions.
> > 
> > Ohh lord, this must have been written before the birth of the saviour uoti.
> > 
> > > In addition, -D_ISOC99_SOURCE would work in all compilers,
> > > not just gcc (though ICC probably supports it anyway and no other
> > > compiler is supported. Still...).
> > 
> > Heretic, dont you know that all compilers must use the --std=gnu99 switch
> > to enable ISO C99 mode, how can you dare to even mention a standard
> > compliant solution. --std=gnu99 must be used the saviour has decided
> > and he knows what is best.
> > Dont be blinded by the mention of these defines in the POSIX spec, they
> > have been placed by the devil there to confuse you. --std=gnu99 is the
> > only and best way to compile C99 programs!
> 
> Stop flaming already.

And accept the lies of uoti and your lack of any clue about the subject?

As an example of one of uotis lies, try
--std=c99 -fasm it will compile asm() just fine.


> 
> -std=gnu99 is closer to C99 than -std=gnu89, period.  

That may be true but we did NOT explicitly use -std=gnu89


> This change
> already helped find and fix some non-C99 constructs in FFmpeg.  If you
> want to see -std=c99 used, then make FFmpeg compilable with that flag,
> which is a prerequisite for MPlayer to use it.

I did not suggest --std=c99 to be used. I just said that there are many
solutions and --std=gnu99 is the worst. And not what we want at all ...
Of course that does not mean that --std=c99 should not be considered, just
that these 2 are not the only options.


What iam saying all along is that the standard way to enable various C99 
prototypes in the headers is
-D_ISOC99_SOURCE or -D_XOPEN_SOURCE=600 or _POSIX_C_SOURCE

These are documented for that purpose in the man pages as shown by reimar
and you can look at the official POSIX standard for example at
www.opengroup.org. It as well mentions these defines.

What -std=gnu99 enables is nowhere clearly defined. Its not mentioned in any
standard document. The assumtation that gnu99 would enable exactly what
we want to use and nothing we do not want to use due to portability issues
is ridiculous.
How could gcc even know what we want? Compared to what other lets say gnu
projects want?
Its clear gnu99 enabled one of the #defines mentioned above otherwise the
missing prototypes would not be there as they are protected by #ifdefs
Its also clear it enabled -fasm.
What else does it enable? Do we want all of it?
Why do we not just enable one of the defines directly like the standards
recommand??? This would work with any compiler. --std=gnu99 will only
work with gnu compatible compilers. 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20080714/3b248ec5/attachment.pgp>