r14484 - in trunk/libavcodec: audioconvert.c audioconvert.h
Author: pross Date: Thu Jul 31 14:55:06 2008 New Revision: 14484 Log: Add sample format support functions: avcodec_get_sample_fmt_name(), avcodec_get_sample_fmt(), avcodec_sample_fmt_string() Added: trunk/libavcodec/audioconvert.h Modified: trunk/libavcodec/audioconvert.c Modified: trunk/libavcodec/audioconvert.c ============================================================================== --- trunk/libavcodec/audioconvert.c (original) +++ trunk/libavcodec/audioconvert.c Thu Jul 31 14:55:06 2008 @@ -25,7 +25,49 @@ * @author Michael Niedermayer <michaelni at gmx.at> */ -#include "avcodec.h" +#include "audioconvert.h" + +typedef struct SampleFmtInfo { + const char *name; + int bits; +} SampleFmtInfo; + +/** this table gives more information about formats */ +static const SampleFmtInfo sample_fmt_info[SAMPLE_FMT_NB] = { + [SAMPLE_FMT_U8] = { .name = "u8", .bits = 8 }, + [SAMPLE_FMT_S16] = { .name = "s16", .bits = 16 }, + [SAMPLE_FMT_S24] = { .name = "s24", .bits = 24 }, + [SAMPLE_FMT_S32] = { .name = "s32", .bits = 32 }, + [SAMPLE_FMT_FLT] = { .name = "flt", .bits = 32 } +}; + +const char *avcodec_get_sample_fmt_name(int sample_fmt) +{ + if (sample_fmt < 0 || sample_fmt >= SAMPLE_FMT_NB) + return NULL; + return sample_fmt_info[sample_fmt].name; +} + +enum SampleFormat avcodec_get_sample_fmt(const char* name) +{ + int i; + + for (i=0; i < SAMPLE_FMT_NB; i++) + if (!strcmp(sample_fmt_info[i].name, name)) + return i; + return SAMPLE_FMT_NONE; +} + +void avcodec_sample_fmt_string (char *buf, int buf_size, int sample_fmt) +{ + /* print header */ + if (sample_fmt < 0) + snprintf (buf, buf_size, "name " " depth"); + else if (sample_fmt < SAMPLE_FMT_NB) { + SampleFmtInfo info= sample_fmt_info[sample_fmt]; + snprintf (buf, buf_size, "%-6s" " %2d ", info.name, info.bits); + } +} int av_audio_convert(void *maybe_dspcontext_or_something_av_convert_specific, void *out[6], int out_stride[6], enum SampleFormat out_fmt, Added: trunk/libavcodec/audioconvert.h ============================================================================== --- (empty file) +++ trunk/libavcodec/audioconvert.h Thu Jul 31 14:55:06 2008 @@ -0,0 +1,57 @@ +/* + * audio conversion + * Copyright (c) 2006 Michael Niedermayer <michaelni at gmx.at> + * Copyright (c) 2008 Peter Ross + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef FFMPEG_AUDIOCONVERT_H +#define FFMPEG_AUDIOCONVERT_H + +/** + * @file audioconvert.h + * Audio format conversion routines + */ + + +#include "avcodec.h" + + +/** + * Generate string corresponding to the sample format with + * number sample_fmt, or a header if sample_fmt is negative. + * + * @param[in] buf the buffer where to write the string + * @param[in] buf_size the size of buf + * @param[in] sample_fmt the number of the sample format to print the corresponding info string, or + * a negative value to print the corresponding header. + * Meaningful values for obtaining a sample format info vary from 0 to SAMPLE_FMT_NB -1. + */ +void avcodec_sample_fmt_string(char *buf, int buf_size, int sample_fmt); + +/** + * @return NULL on error + */ +const char *avcodec_get_sample_fmt_name(int sample_fmt); + +/** + * @return SAMPLE_FMT_NONE on error + */ +enum SampleFormat avcodec_get_sample_fmt(const char* name); + +#endif /* FFMPEG_AUDIOCONVERT_H */
pross wrote:
Author: pross Date: Thu Jul 31 14:55:06 2008 New Revision: 14484
Log: Add sample format support functions: avcodec_get_sample_fmt_name(), avcodec_get_sample_fmt(), avcodec_sample_fmt_string()
Added: trunk/libavcodec/audioconvert.h Modified: trunk/libavcodec/audioconvert.c
Modified: trunk/libavcodec/audioconvert.c ============================================================================== --- trunk/libavcodec/audioconvert.c (original) +++ trunk/libavcodec/audioconvert.c Thu Jul 31 14:55:06 2008 @@ -25,7 +25,49 @@ * @author Michael Niedermayer <michaelni at gmx.at> */
-#include "avcodec.h" +#include "audioconvert.h" + +typedef struct SampleFmtInfo { + const char *name; + int bits; +} SampleFmtInfo; + +/** this table gives more information about formats */ +static const SampleFmtInfo sample_fmt_info[SAMPLE_FMT_NB] = { + [SAMPLE_FMT_U8] = { .name = "u8", .bits = 8 }, + [SAMPLE_FMT_S16] = { .name = "s16", .bits = 16 }, + [SAMPLE_FMT_S24] = { .name = "s24", .bits = 24 }, + [SAMPLE_FMT_S32] = { .name = "s32", .bits = 32 }, + [SAMPLE_FMT_FLT] = { .name = "flt", .bits = 32 } +};
We need a scaled biased float format also. SAMPLE_FMT_SBF = { .name = "sbf", .bits = 32 }might be ok. MvH Benjamin Larsson
pross wrote:
Modified: trunk/libavcodec/audioconvert.c ============================================================================== --- trunk/libavcodec/audioconvert.c (original) +++ trunk/libavcodec/audioconvert.c Thu Jul 31 14:55:06 2008 @@ -25,7 +25,49 @@ * @author Michael Niedermayer <michaelni at gmx.at> */
-#include "avcodec.h"
why did you remove this one ? isn't it needed by the file ? -- Benoit Fouet Purple Labs S.A. www.purplelabs.com
On Thu, Jul 31, 2008 at 03:35:05PM +0200, Benoit Fouet wrote:
pross wrote:
Modified: trunk/libavcodec/audioconvert.c ============================================================================== --- trunk/libavcodec/audioconvert.c (original) +++ trunk/libavcodec/audioconvert.c Thu Jul 31 14:55:06 2008 @@ -25,7 +25,49 @@ * @author Michael Niedermayer <michaelni at gmx.at> */
-#include "avcodec.h"
why did you remove this one ? isn't it needed by the file ?
avcodec.h is provided by audioconvert.h. Indeed, this change was unnecessary and could have been comitted later, seperately. I'll avoid such changes in future... -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
On Fri, 1 Aug 2008 00:11:15 +1000 pross at xvid.org wrote:
On Thu, Jul 31, 2008 at 03:35:05PM +0200, Benoit Fouet wrote:
pross wrote:
Modified: trunk/libavcodec/audioconvert.c ============================================================================== --- trunk/libavcodec/audioconvert.c (original) +++ trunk/libavcodec/audioconvert.c Thu Jul 31 14:55:06 2008 @@ -25,7 +25,49 @@ * @author Michael Niedermayer <michaelni at gmx.at> */
-#include "avcodec.h"
why did you remove this one ? isn't it needed by the file ?
avcodec.h is provided by audioconvert.h.
Indeed, this change was unnecessary and could have been comitted later, seperately. I'll avoid such changes in future...
Not only unnecessary, but even bad. The usage here is that every file must include every headers that it requires directly. You should not rely on one header including another (except when it's explicitely documented so, such as inttypes.h including stdint.h). So here you should add back the avcodec.h include. Aurel
On Thu, 31 Jul 2008 16:32:20 +0200, Aurelien Jacobs wrote:
Not only unnecessary, but even bad. The usage here is that every file must include every headers that it requires directly. You should not rely on one header including another (except when it's explicitely documented so, such as inttypes.h including stdint.h). So here you should add back the avcodec.h include.
is this policy documented somewhere? -compn
On Thu, Jul 31, 2008 at 01:11:14PM -0400, compn wrote:
On Thu, 31 Jul 2008 16:32:20 +0200, Aurelien Jacobs wrote:
Not only unnecessary, but even bad. The usage here is that every file must include every headers that it requires directly. You should not rely on one header including another (except when it's explicitely documented so, such as inttypes.h including stdint.h). So here you should add back the avcodec.h include.
is this policy documented somewhere?
it has not even been discussed or agreed upon yet ... Besides maybe we can make the converter independant of avcodec.h Which seems better either way ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
On Thu, Jul 31, 2008 at 07:47:05PM +0200, Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 01:11:14PM -0400, compn wrote:
On Thu, 31 Jul 2008 16:32:20 +0200, Aurelien Jacobs wrote:
Not only unnecessary, but even bad. The usage here is that every file must include every headers that it requires directly. You should not rely on one header including another (except when it's explicitely documented so, such as inttypes.h including stdint.h). So here you should add back the avcodec.h include.
is this policy documented somewhere?
it has not even been discussed or agreed upon yet ...
Besides maybe we can make the converter independant of avcodec.h Which seems better either way ...
and just to repeat my view on the headers inclusion IMHO headers should NOT include other headers, this nicely avoids such problems ... And iam not suggesting above as a strict always to follow rule, but rather a strong suggestion. There may be situations where a #include in a header makes sense but here as long as SAMPLE_FMT* is in avcodec.h. Any user of audioconvert.c will need to include avcodec.h. Having audioconvert.h include it as well will just confuse people. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 07:47:05PM +0200, Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 01:11:14PM -0400, compn wrote:
is this policy documented somewhere?
it has not even been discussed or agreed upon yet ...
Besides maybe we can make the converter independant of avcodec.h Which seems better either way ...
and just to repeat my view on the headers inclusion IMHO headers should NOT include other headers, this nicely avoids such problems ...
It also leads to the case where including one header leads to needing to include another header, which might in turn need another header, et cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken. In this case, audioconvert.h needs the SampleFormat enum, so it should provide that. If that requires including avformat.h in audioconvert.h, then that is what should happen; if headers should not include other headers unless documented to do so, then the answer would be to so document it rather than to break the header again. -- The Wanderer appears to be surprisingly argumentative today Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 07:47:05PM +0200, Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 01:11:14PM -0400, compn wrote:
is this policy documented somewhere?
it has not even been discussed or agreed upon yet ...
Besides maybe we can make the converter independant of avcodec.h Which seems better either way ...
and just to repeat my view on the headers inclusion IMHO headers should NOT include other headers, this nicely avoids such problems ...
It also leads to the case where including one header leads to needing to include another header, which might in turn need another header, et
which is not available and compilation fails. The user now who just wants to use the part has to hack the headers instead of adding a 5 line enum before the header that needs it. Or maybe the functionality is available but in a different header ... Or the application breaks randomly until the user realized that audioconvert.h included acodec.h that included common.h that included assert.h and one of the headers defined NDEBUG thus disabling asserts. and rendering the user own #include <assert.h> worthless (this one actually happened to me once with assert and some headers i dont remember ...) Some more concrete examples avcodec.h uses int64_t, if it would #include inttypes.h it would be between unuseable to a PITA in any environment that does not have inttypes.h. libavcodec may be compiled with gcc + glibc in a gnu environment. but it might be used in VC++ or another obscure environment that lacks these headers. The rule of including headers in headers is a absolute pain for some use cases to deal with. The advantage of this is purely "because its the right way". The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken.
Do you have a argument beyond "is broken" vs. "is the right way"? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
On Fri, 2008-08-01 at 03:27 +0200, Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
It also leads to the case where including one header leads to needing to include another header, which might in turn need another header, et
which is not available and compilation fails.
So you think trial and error is a good way to set the dependencies? In such an inclusion system it is pretty much the only way. And it doesn't work if some indirect dependencies are conditional or change later.
Or the application breaks randomly until the user realized that audioconvert.h included acodec.h that included common.h that included assert.h and one of the headers defined NDEBUG thus disabling asserts. and rendering the user own #include <assert.h> worthless (this one actually happened to me once with assert and some headers i dont remember ...)
I think defining NDEBUG in a normal header is a bug. That doesn't say much about the inclusion style in general.
Some more concrete examples avcodec.h uses int64_t, if it would #include inttypes.h it would be between unuseable to a PITA in any environment that does not have inttypes.h.
It does already include inttypes.h indirectly through libavutil headers.
libavcodec may be compiled with gcc + glibc in a gnu environment. but it might be used in VC++ or another obscure environment that lacks these headers.
If you create such workaround definitions it's not much more work to place them in a header named "inttypes.h".
The rule of including headers in headers is a absolute pain for some use cases to deal with. The advantage of this is purely "because its the right way".
There was a thread about this on mplayer-dev-eng not too long ago that explained much more significant advantages. The main point is that it's realistic to keep the #include statements in a .c or .h file (mostly) in sync with what is needed _within that file_; it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
I think they include more than you thought (I think pretty much everything ends up including the <inttypes.h> you talked about above for example). More like it doesn't cause much of a problem even though it IS done.
cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken.
Do you have a argument beyond "is broken" vs. "is the right way"?
See above.
On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
On Fri, 2008-08-01 at 03:27 +0200, Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote: [...] Some more concrete examples avcodec.h uses int64_t, if it would #include inttypes.h it would be between unuseable to a PITA in any environment that does not have inttypes.h.
It does already include inttypes.h indirectly through libavutil headers.
interresting, how much time did i took you to find that out? How much do you think it might cause a average developer who debugs a problem related to it?
libavcodec may be compiled with gcc + glibc in a gnu environment. but it might be used in VC++ or another obscure environment that lacks these headers.
If you create such workaround definitions it's not much more work to place them in a header named "inttypes.h".
as long as there is no inttypes.h already that maybe just misses half of the things.
The rule of including headers in headers is a absolute pain for some use cases to deal with. The advantage of this is purely "because its the right way".
There was a thread about this on mplayer-dev-eng not too long ago that explained much more significant advantages. The main point is that it's realistic to keep the #include statements in a .c or .h file (mostly) in sync with what is needed _within that file_;
really? then explain me why they are totally OUT of sync in libav*, since this new idiotic system was adopted?
it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
It worked in mplayer under arpi without a single issue i can remember. So all the pretty arguments stand in stark contrast to actual practice.
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
I think they include more than you thought (I think pretty much everything ends up including the <inttypes.h> you talked about above for example). More like it doesn't cause much of a problem even though it IS done.
So it doesnt concern you that even i as maintainer of libav* has lost track of which header includes which? Well i guess as long as "the right way" is followed everyone will be happy ...
cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken.
Do you have a argument beyond "is broken" vs. "is the right way"?
See above.
above says that there was some thread on some mplayer ML, if thats all you have thats not much. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
On Fri, 2008-08-01 at 14:42 +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
On Fri, 2008-08-01 at 03:27 +0200, Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
[...]
Some more concrete examples avcodec.h uses int64_t, if it would #include inttypes.h it would be between unuseable to a PITA in any environment that does not have inttypes.h.
It does already include inttypes.h indirectly through libavutil headers.
interresting, how much time did i took you to find that out? How much do you think it might cause a average developer who debugs a problem related to it?
Not much time because I already thought it did and I just verified that. I think it's usually not too hard to find out what gets included by looking at precompiled source for example. That "average developer" question depends on the details of the problem.
The rule of including headers in headers is a absolute pain for some use cases to deal with. The advantage of this is purely "because its the right way".
There was a thread about this on mplayer-dev-eng not too long ago that explained much more significant advantages. The main point is that it's realistic to keep the #include statements in a .c or .h file (mostly) in sync with what is needed _within that file_;
really? then explain me why they are totally OUT of sync in libav*, since this new idiotic system was adopted?
Out of sync how?
it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
It worked in mplayer under arpi without a single issue i can remember.
So all the pretty arguments stand in stark contrast to actual practice.
MPlayer files included lots of unnecessary headers after dependencies changed. If you include headers in .c files only then in practice you need to add the indirectly needed headers by trial and error. This mostly produces a result that works originally, but it's already somewhat inefficient, especially if you don't immediately know which other header you should include for a particular missing symbol. If there are conditional dependencies then they're very likely to be missed if they aren't needed on the developer's own system. The case when the indirect dependencies of a header _change_ is a major problem if you don't handle them directly in the header itself. You'd need to change every file where the header ends up being included. Some of those files may not be compiled on your system, and even if they are in case of removed dependencies it's hard to know whether they're still indirectly needed by some _other_ included header.
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
I think they include more than you thought (I think pretty much everything ends up including the <inttypes.h> you talked about above for example). More like it doesn't cause much of a problem even though it IS done.
So it doesnt concern you that even i as maintainer of libav* has lost track of which header includes which? Well i guess as long as "the right way" is followed everyone will be happy ...
There's usually no need to know exactly which headers end up being included. If you do need to know it's not too hard to find out. If the set of headers is conditional on configuration then that list might not have everything that _could_ get included; but the alternative without headers including each other would most likely be that those conditional headers wouldn't be included even when needed, which is worse.
cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken.
Do you have a argument beyond "is broken" vs. "is the right way"?
See above.
above says that there was some thread on some mplayer ML, if thats all you have thats not much.
I did also give specific reasons, but going through all the same things again a few months later is boring...
On Fri, Aug 01, 2008 at 07:19:54PM +0300, Uoti Urpala wrote:
On Fri, 2008-08-01 at 14:42 +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
On Fri, 2008-08-01 at 03:27 +0200, Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote: [...] The rule of including headers in headers is a absolute pain for some use cases to deal with. The advantage of this is purely "because its the right way".
There was a thread about this on mplayer-dev-eng not too long ago that explained much more significant advantages. The main point is that it's realistic to keep the #include statements in a .c or .h file (mostly) in sync with what is needed _within that file_;
really? then explain me why they are totally OUT of sync in libav*, since this new idiotic system was adopted?
Out of sync how?
in the sense that it is easier to find a file that does not include its dependancies directly than one that does. example opt.h includes only libavutil/rational.h but uses int64_t
it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
It worked in mplayer under arpi without a single issue i can remember.
So all the pretty arguments stand in stark contrast to actual practice.
MPlayer files included lots of unnecessary headers after dependencies changed.
Including all dependancies directly also causes many things to be included several times redundantly. [...]
cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken.
Do you have a argument beyond "is broken" vs. "is the right way"?
See above.
above says that there was some thread on some mplayer ML, if thats all you have thats not much.
I did also give specific reasons, but going through all the same things again a few months later is boring...
no problem [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
On Fri, Aug 01, 2008 at 11:59:41PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 07:19:54PM +0300, Uoti Urpala wrote:
On Fri, 2008-08-01 at 14:42 +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
It worked in mplayer under arpi without a single issue i can remember.
So all the pretty arguments stand in stark contrast to actual practice.
MPlayer files included lots of unnecessary headers after dependencies changed.
Including all dependancies directly also causes many things to be included several times redundantly.
No problem, we have multiple inclusion guards everywhere. Diego
On Sat, Aug 02, 2008 at 12:13:13AM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 11:59:41PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 07:19:54PM +0300, Uoti Urpala wrote:
On Fri, 2008-08-01 at 14:42 +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
It worked in mplayer under arpi without a single issue i can remember.
So all the pretty arguments stand in stark contrast to actual practice.
MPlayer files included lots of unnecessary headers after dependencies changed.
Including all dependancies directly also causes many things to be included several times redundantly.
No problem, we have multiple inclusion guards everywhere.
The multple inclusion guards are in the header files not around the #includes file.c #include <stdint.h> #include "avcodec.h" avcodec.h #include <stdint.h> #include "avutil.h" avutil.h #include <stdint.h> #include "common.h" common.h #include <stdint.h> stdint.h #ifndef BLAH #define BLAH [lots of stuff] #endif will cause stdint.h to be parsed 4 times, the compiler has to, it has to find the correct #endif each time it hits stdint.h. There likely a more than 1 #endif in it, it cant skip the #if /#else stuff in the middle [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
On 8/2/08, Michael Niedermayer <michaelni at gmx.at> wrote:
On Sat, Aug 02, 2008 at 12:13:13AM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 11:59:41PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 07:19:54PM +0300, Uoti Urpala wrote:
On Fri, 2008-08-01 at 14:42 +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
It worked in mplayer under arpi without a single issue i can remember.
So all the pretty arguments stand in stark contrast to actual practice.
MPlayer files included lots of unnecessary headers after dependencies changed.
Including all dependancies directly also causes many things to be included several times redundantly.
No problem, we have multiple inclusion guards everywhere.
The multple inclusion guards are in the header files not around the #includes
file.c #include <stdint.h> #include "avcodec.h"
avcodec.h #include <stdint.h> #include "avutil.h"
avutil.h #include <stdint.h> #include "common.h"
common.h #include <stdint.h>
stdint.h #ifndef BLAH #define BLAH [lots of stuff] #endif
will cause stdint.h to be parsed 4 times, the compiler has to, it has to find the correct #endif each time it hits stdint.h. There likely a more than 1 #endif in it, it cant skip the #if /#else stuff in the middle
I do like the explicit inclusion system. I've argued before why I like it. But indeed mans' argument is valid - it needs to be replicated in each .c file. Then how about making it in 2 levels? Each .c file includes only one header. This header contains all other headers in predetermined order. It may even speedup build if using precompiled headers. (gcc is supposed to support them since v3.4) Well, maybe instead of single header we may have 2 or 3. e.g. system_includes, public_include and internal_includes. After doing this nobody should be worried if and where the headers he needs are included ... I guess that common.h have been the first step in that direction, but we never got to the second ;)
On Sat, 2008-08-02 at 00:33 +0200, Michael Niedermayer wrote:
The multple inclusion guards are in the header files not around the #includes
file.c #include <stdint.h> #include "avcodec.h"
avcodec.h #include <stdint.h> #include "avutil.h"
avutil.h #include <stdint.h> #include "common.h"
common.h #include <stdint.h>
stdint.h #ifndef BLAH #define BLAH [lots of stuff] #endif
will cause stdint.h to be parsed 4 times, the compiler has to, it has to find the correct #endif each time it hits stdint.h. There likely a more than 1 #endif in it, it cant skip the #if /#else stuff in the middle
GCC would not parse it 4 times. It has some optimization that records whether a file was completely wrapped inside a conditional controlled by a macro, and skips parsing it again if the macro is defined. I made a test file which #included avcodec.h a million times (61 MB file with longish path in the #include) and GCC preprocessed it in under 2 seconds.
On Fri, Aug 01, 2008 at 02:42:36PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
it's not realistic to keep them in sync with indirect dependencies, at least not without automated tools that aren't used in practice.
It worked in mplayer under arpi without a single issue i can remember.
No matter if you can remember it or not, I can assure you that I have cursed many times. Diego
Michael Niedermayer <michaelni at gmx.at> writes:
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
Actually, *all* our headers #include their dependencies. That's what "make checkheaders" makes sure. Mike, could you add "make checkheaders" to the FATE tests, so we notice any breakage immediately? -- M?ns Rullg?rd mans at mansr.com
On Fri, Aug 01, 2008 at 09:39:16AM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
Actually, *all* our headers #include their dependencies. That's what "make checkheaders" makes sure.
avcodec.h does not include inttypes or stdint directly but use int64_t and iam sure it would be easier to find headers missing dependencies than ones listing all. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 09:39:16AM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
Actually, *all* our headers #include their dependencies. That's what "make checkheaders" makes sure.
avcodec.h does not include inttypes or stdint directly but use int64_t and iam sure it would be easier to find headers missing dependencies than ones listing all.
avcodec.h includes common.h, which does include stdint.h. As I said, common.h is a special case. Its purpose is to avoid duplicating code that would have to be in practically every file otherwise, and this includes including stdint.h. Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain method can, if enough force is applied, achieve a working end result, does not in any way whatsoever make it a good method. -- M?ns Rullg?rd mans at mansr.com
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 09:39:16AM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers they somehow depend on.
Actually, *all* our headers #include their dependencies. That's what "make checkheaders" makes sure.
avcodec.h does not include inttypes or stdint directly but use int64_t and iam sure it would be easier to find headers missing dependencies than ones listing all.
avcodec.h includes common.h, which does include stdint.h. As I said,
no, avcodec.h does not directly include common.h it includes avutil.h that includes common.h which includes inttypes.h Its kinda ironic that you know the header inclusion chains we have nowadays as well as i aka not at all. (without RTFS of course, anyone can figure it out by RTFS ...)
common.h is a special case. Its purpose is to avoid duplicating code that would have to be in practically every file otherwise, and this includes including stdint.h.
its inttypes.h which it does include, be that correct or not but its not stdint.h. It certainly could be annoying if stdint is available but inttypes is not in some build environment ...
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality. also a quick grep indicates that i have 49 .{c,h} files that contain int64_t but not stdint, inttypes nor common.h in libavcodec. Not sure how many exceptions ive missed that may be used in the new system as substitutions for inttypes. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting.
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before? Hyphothetical claims have been given but these have never actually occured prior to this rule in ffmpeg. While now after the rule developers are being asked to follow it if they do not, that undoubtly costs extra time. Its not as if the code works better or worse if indirect inclusion is used compared to direct. But having to deal with the question "which headers do i need" is much easier based on a "the ones that contain the things in the error and warning messages" than "the ones listed in the standard for every function enum, struct, ... used in the current file" What iam saying is that the rule of direct inclusion is not practically doable plain because there is no automatic way that tells one what is missing when it is already available indirectly. Considering this i think its unfair to pick people out and flame them for breaking that rule. Do you always know (without checking the specs) which header is needed for every function? I do not, so how should i or anyone else add the correct headers when all prototypes are already available indirectly so there are no warnings or anything at all that would hint at what is missing? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
There hasn't been much of a problem, simply because the rule was followed to a large degree prior to anyone calling it a rule.
Hyphothetical claims have been given but these have never actually occured prior to this rule in ffmpeg. While now after the rule developers are being asked to follow it if they do not, that undoubtly costs extra time. Its not as if the code works better or worse if indirect inclusion is used compared to direct.
I have had the misfortune of working (in companies) on projects where the rule was to *never* include header in other headers. Believe me, it was not fun. By advocating the rule of
But having to deal with the question "which headers do i need" is much easier based on a "the ones that contain the things in the error and warning messages" than "the ones listed in the standard for every function enum, struct, ... used in the current file"
What iam saying is that the rule of direct inclusion is not practically doable plain because there is no automatic way that tells one what is missing when it is already available indirectly.
You raise a valid point, and it is something I indeed would like to see a solution for. Refusing to do the right thing even when you *do* happen to know the requirements does not solve this problem.
Considering this i think its unfair to pick people out and flame them for breaking that rule.
I agree, and don't flame people for breaking the rule by accident.
Do you always know (without checking the specs) which header is needed for every function?
For functions I use frequently, yes. If I'm unsure, I check the specs.
I do not, so how should i or anyone else add the correct headers when all prototypes are already available indirectly so there are no warnings or anything at all that would hint at what is missing?
It shouldn't be too difficult to write a simple tool for finding the dependencies. A gcc option to do it would of course be nicer, but I personally have no intention of touching gcc code. -- M?ns Rullg?rd mans at mansr.com
On Fri, Aug 01, 2008 at 05:04:34PM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
There hasn't been much of a problem, simply because the rule was followed to a large degree prior to anyone calling it a rule.
It seems we are very seriously misunderstanding each other. The "rule" that every file always directly includes its dependancies has never been followed, not even remotely. There is a very large difference between somehow including all dependancies in every file possibly indirectly through various headers and the "rule" that all dependancies must be directly included. This thread started because people complained about peter changing a direct inclusion of avcodec.h to a indirect inclusion over audioconvert.h. So i assumed that is what your "rule" is about. And this is what iam arguing against. Such rule is insane and has never been followed in any project i know. If you disagree iam curious which project is following such rule? The gnu system headers very certainly not, they use various headers to include other headers. [...]
I do not, so how should i or anyone else add the correct headers when all prototypes are already available indirectly so there are no warnings or anything at all that would hint at what is missing?
It shouldn't be too difficult to write a simple tool for finding the dependencies. A gcc option to do it would of course be nicer, but I personally have no intention of touching gcc code.
Could you please explain me, WHAT is better if all files redundantly include their dependancies directly instead of for example audioconvert.c including audioconvert.h that includes avcodec.h ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
I can give you one very concrete example that just bit me: I added ffaac support to my local MPlayer tree by importing the SoC stuff into it. Compilation of aac.c failed because it was missing math.h and string.h headers. But the first error message was about ENOMEM which puzzled me. This did indeed take some time to fix, which could have been avoided if Robert had #included all necessary headers from the start. Diego
On Fri, Aug 01, 2008 at 06:20:42PM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
I can give you one very concrete example that just bit me: I added ffaac support to my local MPlayer tree by importing the SoC stuff into it. Compilation of aac.c failed because it was missing math.h and string.h headers. But the first error message was about ENOMEM which puzzled me.
This did indeed take some time to fix, which could have been avoided if Robert had #included all necessary headers from the start.
yes, but this has nothing to do with the discussion at hand. noone has suggested to NOT include the needed headers. if robert forgot the headers no variant of the rule would have avoided that. Iam arguing against a rule of direct inclusion of all headers, mans is apparently arguing in favor of such rule in some of his mails though others contradict this again. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On Fri, Aug 01, 2008 at 11:39:27PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 06:20:42PM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
I can give you one very concrete example that just bit me: I added ffaac support to my local MPlayer tree by importing the SoC stuff into it. Compilation of aac.c failed because it was missing math.h and string.h headers. But the first error message was about ENOMEM which puzzled me.
This did indeed take some time to fix, which could have been avoided if Robert had #included all necessary headers from the start.
yes, but this has nothing to do with the discussion at hand. noone has suggested to NOT include the needed headers.
if robert forgot the headers no variant of the rule would have avoided that.
False. It compiled fine in FFmpeg where it was getting the necessary headers from somewhere, but not in MPlayer where the headers were not provided. I did not bother investigating in detail after the issue was fixed but I suspect that HAVE_AV_CONFIG_H was #defined in one case, but not the other. Now if Robert had followed the rule of directly including all required headers instead of relying on indirect inclusion, then this problem would not have happened in the first place. Diego
On Fri, Aug 01, 2008 at 11:54:32PM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 11:39:27PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 06:20:42PM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
I can give you one very concrete example that just bit me: I added ffaac support to my local MPlayer tree by importing the SoC stuff into it. Compilation of aac.c failed because it was missing math.h and string.h headers. But the first error message was about ENOMEM which puzzled me.
This did indeed take some time to fix, which could have been avoided if Robert had #included all necessary headers from the start.
yes, but this has nothing to do with the discussion at hand. noone has suggested to NOT include the needed headers.
if robert forgot the headers no variant of the rule would have avoided that.
False. It compiled fine in FFmpeg where it was getting the necessary headers from somewhere, but not in MPlayer where the headers were not provided. I did not bother investigating in detail after the issue was fixed but I suspect that HAVE_AV_CONFIG_H was #defined in one case, but not the other.
Now if Robert had followed the rule of directly including all required headers instead of relying on indirect inclusion, then this problem would not have happened in the first place.
yes but let me remind you that mans rule was all headers directly except what common.h and internal.h provides. And these provide your missng headers under #ifdef HAVE_AV_CONFIG_H so while it would have worked under the rule you quote, that is not what mans rule is. Its not possible for people to follow such volatile and speaker dependant rules. So i suggest that you and mans first decide on what shiny rule you actually argue for. It clearly doesnt seem to be matching each others currently. Though both of you pretend it does. And i have the weak feeling that you two unconciously adapt the rule from mail to mail to make it work best. Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly.
All files should #include everything they need directly. Diego
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly.
All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough. Note that 'make checkheaders' does not strictly enforce this, but at least it makes sure that headers work standalone, i.e. that they can be used without having to worry about which other #include lines to add. Diego
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly.
All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols? I see no reason why we could not use the same "documented to include" rationale for internal headers as is used for some external ones. Indeed, I think that would potentially be better. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly.
All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols?
Same thing. Let me try to state exactly what I want the rule to be: For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro. Is this unambiguous enough? -- M?ns Rullg?rd mans at mansr.com
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly.
All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols?
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, thank you! I do not want to make a premature statement but i think this suggestion would be acceptable. Though it is certainly not what diego suggested nor how i understood your previous mails. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
2008/8/3 Michael Niedermayer <michaelni at gmx.at>:
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly.
All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols?
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, thank you!
I do not want to make a premature statement but i think this suggestion would be acceptable.
Sounds good and sensible to me. Rob
On Sun, Aug 03, 2008 at 05:24:19PM +0200, Michael Niedermayer wrote:
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, thank you!
I do not want to make a premature statement but i think this suggestion would be acceptable. Though it is certainly not what diego suggested nor how i understood your previous mails.
It is what I suggested, or at least tried to. We just need to clarify what indirectly providing means. It should be something like "A is documented to provide B and this will never change". Diego
Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 05:24:19PM +0200, Michael Niedermayer wrote:
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
I absolutely agree with this.
It is what I suggested, or at least tried to.
We just need to clarify what indirectly providing means. It should be something like "A is documented to provide B and this will never change".
I think that's what M?ns tried to express with "guaranteed to provide". Now the only problem left with this proposition is that we currently have no header granting the inclusion of other headers. We probably all consider that common.h grants the inclusion of inttypes.h, but it's not written anywhere. So added to the above definition, we also need a written list of guarantee such as the following (very incomplete) one: avutil.h guarantee inclusion of: common.h avcodec.h guarantee inclusion of: common.h avformat.h guarantee inclusion of: common.h common.h guarantee inclusion of: inttypes.h mem.h Aurel
On Sun, Aug 03, 2008 at 05:51:10PM +0200, Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 05:24:19PM +0200, Michael Niedermayer wrote:
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, thank you!
I do not want to make a premature statement but i think this suggestion would be acceptable. Though it is certainly not what diego suggested nor how i understood your previous mails.
It is what I suggested, or at least tried to.
We just need to clarify what indirectly providing means.
with slightly different wording: "It is what I suggested, or at least tried to. We just need to redefine what indirectly providing means." id belive it.
It should be something like "A is documented to provide B
Theres nothing wrong with documenting it and iam all for documenting it, but
and this will never change".
the word "never" is not appropriate, headers change, internal headers even more so, and if no file including a header needs an #include anymore it should be droped. Similarly if only 1 file including a header needs something that could be moved to that 1 file. Both these contradict the "never" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
On 8/3/08, Michael Niedermayer <michaelni at gmx.at> wrote:
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
Would it be possible that you could spell out the rule you think is a rule so we all know beyond doubt if there are exceptions and if so which exactly.
All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols?
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, thank you!
I do not want to make a premature statement but i think this suggestion would be acceptable. Though it is certainly not what diego suggested nor how i understood your previous mails.
I do not like it. 1. It doesn't allow declaration or definition to be in the same file (source or header) where it is used. 2. The rule doesn't imply or limit inclusions to the necessary. You can fill headers with useless stuff, without breaking the rule. 3. The "indirect" inclusion is definitely huge step back. 4. There is no need for all headers to be self sustained. I know this is the key to that system, but definition that says "... a file (source or header included by the source)..." would work just as well. Actually as long as we talk about definitions "... file (source)..." is sufficient. This is because the trick is in the word "guaranteed". As long as it is not explicitly defined the whole definition is pure academic exercise .
"Ivan Kalvachev" <ikalvachev at gmail.com> writes:
On 8/3/08, Michael Niedermayer <michaelni at gmx.at> wrote:
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer wrote:
> Would it be possible that you could spell out the rule you think > is a rule so we all know beyond doubt if there are exceptions and > if so which exactly.
All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols?
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, thank you!
I do not want to make a premature statement but i think this suggestion would be acceptable. Though it is certainly not what diego suggested nor how i understood your previous mails.
I do not like it.
1. It doesn't allow declaration or definition to be in the same file (source or header) where it is used.
That was obviously not my intention.
2. The rule doesn't imply or limit inclusions to the necessary. You can fill headers with useless stuff, without breaking the rule.
You can always fill your files with useless stuff.
3. The "indirect" inclusion is definitely huge step back.
A step back from what? In what respect?
4. There is no need for all headers to be self sustained. I know this is the key to that system, but definition that says "... a file (source or header included by the source)..." would work just as well.
That would be a different rule, and one that I consider inferior, because it leads to trouble. Trust me, I've been there.
Actually as long as we talk about definitions "... file (source)..." is sufficient. This is because the trick is in the word "guaranteed". As long as it is not explicitly defined the whole definition is pure academic exercise .
Apparently my rule was not safe against the most hardened trolls. Let me try again: For each type, symbol, or macro referenced in a file (source or header), the file shall either: - contain a declaration or definition of the type, symbol, or macro, or - #include a header file documented to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro. Sorry for the patent-speak, but I want to avoid any possibly ambiguous references. At least I didn't use the word "plurality". -- M?ns Rullg?rd mans at mansr.com
On 8/3/08, M?ns Rullg?rd <mans at mansr.com> wrote:
"Ivan Kalvachev" <ikalvachev at gmail.com> writes:
On 8/3/08, Michael Niedermayer <michaelni at gmx.at> wrote:
On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
> On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer > wrote: > >> Would it be possible that you could spell out the rule you think >> is a rule so we all know beyond doubt if there are exceptions and >> if so which exactly. > > All files should #include everything they need directly.
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols?
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, thank you!
I do not want to make a premature statement but i think this suggestion would be acceptable. Though it is certainly not what diego suggested nor how i understood your previous mails.
I do not like it.
1. It doesn't allow declaration or definition to be in the same file (source or header) where it is used.
That was obviously not my intention.
2. The rule doesn't imply or limit inclusions to the necessary. You can fill headers with useless stuff, without breaking the rule.
You can always fill your files with useless stuff.
3. The "indirect" inclusion is definitely huge step back.
A step back from what? In what respect?
4. There is no need for all headers to be self sustained. I know this is the key to that system, but definition that says "... a file (source or header included by the source)..." would work just as well.
That would be a different rule, and one that I consider inferior, because it leads to trouble. Trust me, I've been there.
I don't see why I should take your (or anybodys' else) words only on trust. Every system have good and bad sides, each system solves some kind of troubles and causes others. I'm sure your system works, but as you alone said "That a certain method can, if enough force is applied, achieve a working end result, does not in any way whatsoever make it a good method." The system you are advocating also have bad sides, you may think they are insignificant, but other people may not think so. We all had some bad experience with headers that we don't want to repeat. I would like you to explain what troubles your system solves, what troubles it causes, why it is good trade off and how much better it is compared to other systems (at least the ones you've tried). The check is the highest form of trust. Enlighten us.
M?ns Rullg?rd wrote:
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
For system headers like inttypes.h that are documented to always #include other headers like stdint.h, I consider just inttypes.h enough.
What about for non-system headers which are, or could be, "documented" (that is, explicitly guaranteed) to always include particular other headers - or, more to the point, provide particular symbols?
Same thing. Let me try to state exactly what I want the rule to be:
For each type, symbol, or macro used in a file (source or header), the file shall contain an #include line guaranteed to provide, directly or indirectly, a declaration or definition of the type, symbol, or macro.
Is this unambiguous enough?
Yes, though it seems a little inconsistent with the previous statement, because the "or indirectly" could easily cover a multitude of sins. If that rule is accepted, then the discussion becomes a matter of how and where to set the guarantees. As I have indicated in the past, I might consider the fact that a header associated with a particular source file uses a particular symbol in a prototype of a function defined in that source file to constitute a guarantee that the header will provide a definition of that symbol for as long as the source file in question needs it, and therefore that the source file does not need to include any other header to provide that symbol. (That's a fairly dense sentence, but any less dense way I've tried seems more ambiguous.) At the same time, another source file which does not define that same function would not necessarily have the same guarantee that the header will always provide that symbol. I can easily see how others might disagree about whether this would actually constitute a "guarantee" in this context. At this point, that is precisely the sort of thing which would need to be discussed and settled on. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
2008/8/1 Diego Biurrun <diego at biurrun.de>:
On Fri, Aug 01, 2008 at 11:39:27PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 06:20:42PM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
I can give you one very concrete example that just bit me: I added ffaac support to my local MPlayer tree by importing the SoC stuff into it. Compilation of aac.c failed because it was missing math.h and string.h headers. But the first error message was about ENOMEM which puzzled me.
This did indeed take some time to fix, which could have been avoided if Robert had #included all necessary headers from the start.
To be fair, it took minimal time to fix.
yes, but this has nothing to do with the discussion at hand. noone has suggested to NOT include the needed headers.
if robert forgot the headers no variant of the rule would have avoided that.
False. It compiled fine in FFmpeg where it was getting the necessary headers from somewhere, but not in MPlayer where the headers were not provided. I did not bother investigating in detail after the issue was fixed but I suspect that HAVE_AV_CONFIG_H was #defined in one case, but not the other.
Now if Robert had followed the rule of directly including all required headers instead of relying on indirect inclusion, then this problem would not have happened in the first place.
I'd just like to point out that the AAC decoder isn't written by me. I've just spent a couple of months or so cleaning it up. Also, it's difficult to know what headers are required without seeing the compilation errors. Usually compilation errors make it obvious what is missing. Adding appropriate headers, recompiling, looking for more errors due to missing headers and adding those doesn't really take that long for one file. Rob
On Sat, Aug 02, 2008 at 08:18:54AM +0100, Robert Swain wrote:
2008/8/1 Diego Biurrun <diego at biurrun.de>:
On Fri, Aug 01, 2008 at 11:39:27PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 06:20:42PM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...] > Now please stop trolling, and get back to coding, which you do very well. > Quite frankly though, I doubt you have the experience necessary to for > an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
I can give you one very concrete example that just bit me: I added ffaac support to my local MPlayer tree by importing the SoC stuff into it. Compilation of aac.c failed because it was missing math.h and string.h headers. But the first error message was about ENOMEM which puzzled me.
This did indeed take some time to fix, which could have been avoided if Robert had #included all necessary headers from the start.
To be fair, it took minimal time to fix.
Whatever you call minimal time. We spent maybe half an hour on it together, I spent something on the order of another half hour on my own. But the point really is that it could easily be avoided. Diego
On Sat, Aug 02, 2008 at 02:53:36PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 08:18:54AM +0100, Robert Swain wrote:
2008/8/1 Diego Biurrun <diego at biurrun.de>:
On Fri, Aug 01, 2008 at 11:39:27PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 06:20:42PM +0200, Diego Biurrun wrote:
On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote: > On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...] > > Now please stop trolling, and get back to coding, which you do very well. > > Quite frankly though, I doubt you have the experience necessary to for > > an informed opinion on organisational matters like these. That a certain > > maybe. I do not claim to be an expert in header inclusion rules and do not > claim to have reviewed dozends of projects what they do and what problems > it causes. I just see how well it "works" here, and how little the claims > match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
I can give you one very concrete example that just bit me: I added ffaac support to my local MPlayer tree by importing the SoC stuff into it. Compilation of aac.c failed because it was missing math.h and string.h headers. But the first error message was about ENOMEM which puzzled me.
This did indeed take some time to fix, which could have been avoided if Robert had #included all necessary headers from the start.
To be fair, it took minimal time to fix.
Whatever you call minimal time. We spent maybe half an hour on it together, I spent something on the order of another half hour on my own. But the point really is that it could easily be avoided.
If it takes you an hour to debug a "missing" include then i think the problem is elsewhere. An error about ENOMEM -> missing errno.h include and if you dont know that, info libc --index-search=ENOMEM tells you, and a grep -r /usr/include likely would have as well. a grep in aac* would tell you its not included, and one in all headers in libav* would have told you its included from common.h ... I dont think its reasonable to solve this by asking all developers of ffmpeg to include all headers in all files redundantly because you might want to rip a file out and use it in mplayer. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
2008/8/1 Michael Niedermayer <michaelni at gmx.at>:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote: [...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has existed MUCH longer than it, and it has never been a problem for _us_ so one has to ask what exactly did this rule fix that caused problems before?
Hyphothetical claims have been given but these have never actually occured prior to this rule in ffmpeg. While now after the rule developers are being asked to follow it if they do not, that undoubtly costs extra time. Its not as if the code works better or worse if indirect inclusion is used compared to direct.
But having to deal with the question "which headers do i need" is much easier based on a "the ones that contain the things in the error and warning messages" than "the ones listed in the standard for every function enum, struct, ... used in the current file"
What iam saying is that the rule of direct inclusion is not practically doable plain because there is no automatic way that tells one what is missing when it is already available indirectly. Considering this i think its unfair to pick people out and flame them for breaking that rule. Do you always know (without checking the specs) which header is needed for every function? I do not, so how should i or anyone else add the correct headers when all prototypes are already available indirectly so there are no warnings or anything at all that would hint at what is missing?
I'm not sure what context to use but the above seemed somewhat relevant to what I thought of as a seemingly significant pro for putting includes in headers for their dependencies - if a header's dependencies change, all files that include that header have to add the new dependency. This seems a bit annoying to me. Rob
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote:
[...]
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Also, its interresting to note that the "all files must directly include their dependancies" rule
This phrasing sounds like the way I described my opinion, but this does not match my opinion. Has this rule been stated by someone else, or is this a misinterpretation of what I said? -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote:
On Fri, Aug 01, 2008 at 09:39:16AM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers
Michael Niedermayer wrote: they
somehow depend on.
Actually, *all* our headers #include their dependencies. That's what "make checkheaders" makes sure.
avcodec.h does not include inttypes or stdint directly but use int64_t and iam sure it would be easier to find headers missing dependencies than ones listing all.
avcodec.h includes common.h, which does include stdint.h. As I said,
no, avcodec.h does not directly include common.h it includes avutil.h that includes common.h which includes inttypes.h
Its kinda ironic that you know the header inclusion chains we have nowadays as well as i aka not at all. (without RTFS of course, anyone can figure it out by RTFS ...)
The exact chains are irrelevant, and that's the point. If every header provides, in one way or another, everything it requires, there is no need to be concerned with the exact details. To further the point, if a header does *not* include its dependencies, no amount of RTFS will tell you what is needed.
common.h is a special case. Its purpose is to avoid duplicating code that would have to be in practically every file otherwise, and this includes including stdint.h.
its inttypes.h which it does include, be that correct or not but its not stdint.h. It certainly could be annoying if stdint is available but inttypes is not in some build environment ...
inttypes.h is documented to include stdint.h, and both are required in a standard system.
Now please stop trolling, and get back to coding, which you do very well. Quite frankly though, I doubt you have the experience necessary to for an informed opinion on organisational matters like these. That a certain
maybe. I do not claim to be an expert in header inclusion rules and do not claim to have reviewed dozends of projects what they do and what problems it causes. I just see how well it "works" here, and how little the claims match reality.
Just as an experiment, why don't you delete all #include lines from our header files, and see how much things break?
also a quick grep indicates that i have 49 .{c,h} files that contain int64_t but not stdint, inttypes nor common.h in libavcodec. Not sure how many exceptions ive missed that may be used in the new system as substitutions for inttypes.
I never said all our code was perfect, and I'm certain finding more examples is easy. That is, however, no excuse for not writing new code properly, nor is it an argument against the general rule. -- M?ns Rullg?rd mans at mansr.com
On Fri, Aug 01, 2008 at 04:50:07PM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote:
On Fri, Aug 01, 2008 at 09:39:16AM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
The only reason why its not causing a problem is plain because its not done, our headers luckily do in general not include all the headers
Michael Niedermayer wrote: they
somehow depend on.
Actually, *all* our headers #include their dependencies. That's what "make checkheaders" makes sure.
avcodec.h does not include inttypes or stdint directly but use int64_t and iam sure it would be easier to find headers missing dependencies than ones listing all.
avcodec.h includes common.h, which does include stdint.h. As I said,
no, avcodec.h does not directly include common.h it includes avutil.h that includes common.h which includes inttypes.h
Its kinda ironic that you know the header inclusion chains we have nowadays as well as i aka not at all. (without RTFS of course, anyone can figure it out by RTFS ...)
The exact chains are irrelevant, and that's the point. If every header provides, in one way or another, everything it requires, there is no need to be concerned with the exact details.
Then please explain me what you meant in your mail that said: " It should not be committed at all. Files should #include all headers they explicitly depend on. The only exceptions to this rule are common.h and internal.h. Please revert this. " avcodec.h is included by audioconvert.h so removial of #include avcodec.h still has it included "one way or another" Do you want every file to directly and litterally include all headers it depends on or is it ok to include another header that somehow causes all dependancies to be included? There is a big difference between these 2 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact
M?ns Rullg?rd wrote:
Mike, could you add "make checkheaders" to the FATE tests, so we notice any breakage immediately?
Certainly. Where should it occur in this sequence of events? configure make make install make -C libswcale ... which are the current build steps. Thanks... -- -Mike Melanson
Mike Melanson wrote:
M?ns Rullg?rd wrote:
Mike, could you add "make checkheaders" to the FATE tests, so we notice any breakage immediately?
Certainly. Where should it occur in this sequence of events?
configure make make install make -C libswcale
... which are the current build steps. Thanks...
It can be run at any point after configure. However, it should be configured as a separate test, since the build can still be fine, even if checkheaders fails. -- M?ns Rullg?rd mans at mansr.com
M?ns Rullg?rd wrote:
Mike Melanson wrote:
M?ns Rullg?rd wrote:
Mike, could you add "make checkheaders" to the FATE tests, so we notice any breakage immediately? Certainly. Where should it occur in this sequence of events?
configure make make install make -C libswcale
... which are the current build steps. Thanks...
It can be run at any point after configure. However, it should be configured as a separate test, since the build can still be fine, even if checkheaders fails.
That is occurring with the current tree. So yes, that is a good idea to configure it as a separate test. I will add it soon but I hope you will fix it soon (I haven't been keeping up -- is that what the current flame war is about?). I don't like red (or even yellow) on the FATE page. BTW, what exactly is checkheaders supposed to do? -- -Mike Melanson
On Sat, Aug 02, 2008 at 11:00:40PM -0700, Mike Melanson wrote:
BTW, what exactly is checkheaders supposed to do?
It checks that headers compile standalone, i.e. that there are no undefined symbols/macros/functions. It is not clever enough to notice indirect inclusion though. Diego
Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
and just to repeat my view on the headers inclusion IMHO headers should NOT include other headers, this nicely avoids such problems
It also leads to the case where including one header leads to needing to include another header, which might in turn need another header, et
which is not available and compilation fails.
But if that other header is not available, compilation would fail anyway, because the original header needs something which is not defined.
The user now who just wants to use the part has to hack the headers instead of adding a 5 line enum before the header that needs it.
And how is the user to know what to add? In the case of the enum it's mildly obvious, but exactly how that enum is defined is not obvious, and finding out how it is defined would require tracking down the header which defines it - which leads to the same problem as before.
Or maybe the functionality is available but in a different header ...
That's a more reasonable argument, but how often - especially, given the context, within a provides-its-own-headers application such as FFmpeg - does that actually arise? I acknowledge that it appears to happen fairly frequently when attempting to include system headers on incompatibly-designed systems, but that's something of a special case IMO.
Or the application breaks randomly until the user realized that audioconvert.h included acodec.h that included common.h that included assert.h and one of the headers defined NDEBUG thus disabling asserts. and rendering the user own #include <assert.h> worthless (this one actually happened to me once with assert and some headers i dont remember ...)
I remember seeing this discussed somewhere once, and yes, I agree that this could be a problem - but I think that I would say that defining NDEBUG in a public header would be at least as bad a thing as e.g. printing to stdout in a library; IOW, this would be a bug in the header.
The rule of including headers in headers is a absolute pain for some use cases to deal with.
I don't doubt or seriously dispute that. The alternative (from at least an end-user tracking-down-the-right-headers perspective) is, however, IMO significantly worse.
The advantage of this is purely "because its the right way".
And just why is it that it is the right way?
The only reason why its not causing a problem is plain because its not done,
It certainly is done - extensively in system headers, if nothing else. (This has indeed caused problems in some cases - longstanding and recurring "conflicting types" bugs in Debian's kernel headers vs. libc headers, for instance - but given how few there seem to be vs. how widespread the headers in question are, I don't think it's an especially major issue.)
our headers luckily do in general not include all the headers they somehow depend on.
(I think that is my opinion that it is impossible for one header to depend on another. A header, like any source file, can depend only on a symbol (or collection of symbols), which can be defined anywhere. That's more a matter of semantics, though.)
cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken.
Do you have a argument beyond "is broken" vs. "is the right way"?
Perhaps a few, but Uoti has made a few which seem sensible to me (although also at least one which does not). The fact that Uoti appears to agree with me is enough to lead me to doubt my own position, but I'm not giving up on it yet. ^_^ -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Fri, Aug 01, 2008 at 06:58:42AM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
Michael Niedermayer wrote: [...] The advantage of this is purely "because its the right way".
And just why is it that it is the right way?
You said "If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken." I felt that this was an argument based on "because it should be done that way" [...]
cetera. If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken.
Do you have a argument beyond "is broken" vs. "is the right way"?
Perhaps a few, but Uoti has made a few which seem sensible to me (although also at least one which does not). The fact that Uoti appears to agree with me is enough to lead me to doubt my own position, but I'm not giving up on it yet. ^_^
;) The thing that really annoys me is that we ended up with some developers trying to enforce a rule of "every file includes all its dependancies directly" while this is 1. not done currently and checkheaders does not check it either. 2. there is no consensus nor was there a vote nor has it been decided by the evil ffmpeg maintainer. 3. if it would really be done strictly it would likely lead to problems, long lists of includes and be a nightmare to keep in sync. What checkheaders checks is that headers somehow compile IIRC, that doesnt distiguish between how a header includes its dependancies. Theres a difference between * every header musts somehow include its dependancies * every header must directly include its dependancies * no header should include any other header [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 06:58:42AM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
The advantage of this is purely "because its the right way".
And just why is it that it is the right way?
You said "If a header needs something then it should provide that thing, either by defining it directly or (more practically) by including another header which already defines it. A header which fails to do so is, IMO, broken."
I felt that this was an argument based on "because it should be done that way"
You may be right about that. I do believe that there are underlying reasons *why* it "should be done that way", but I do not have them ready to hand for immediate explanation. If I have time, I will think about it and see if I can explain my subconscious reasoning.
Do you have a argument beyond "is broken" vs. "is the right way"?
Perhaps a few, but Uoti has made a few which seem sensible to me (although also at least one which does not). The fact that Uoti appears to agree with me is enough to lead me to doubt my own position, but I'm not giving up on it yet. ^_^
;)
The thing that really annoys me is that we ended up with some developers trying to enforce a rule of "every file includes all its dependancies directly"
For the record, that is not what I am advocating; indeed, I believe I would oppose it. (If taken literally, it would require e.g. that every file which includes stdio.h also include the things which are needed by but not defined directly in stdio.h...) What I am saying is that adding a single '#include "file.h"' should never result in *new* undefined symbols (barring things like incompatible header/source versions, of course). I do not think that this is an unreasonable thing to expect. I do admit that there are very likely problems which could, perhaps would, result from the obvious way to ensure that that does not happen (that way being to have headers include other headers). I do not think that they are likely to be as widespread or as severe as you seem to think. This is based, at least in part, on the fact that this approach appears to be used, without apparent severe problems, in the near-universally-used headers of e.g. the kernel and the C library. I also do not think that they are likely to be any more widespread or severe than the problems which could, perhaps would, result from the alternate (opposite?) approach of requiring every source file to include every header it needs, or from most possible neither-nor compromises.
Theres a difference between * every header musts somehow include its dependancies
This is what I (currently believe I) am advocating.
* every header must directly include its dependancies
This is something which I may have supported in the past, and may support again in the future, but am not presently terribly fond of.
* no header should include any other header
This implies "every source file should directly include every header file it needs", and I am not in favor of it at all. In theory, if followed universally, it could perhaps work; however, A) as I believe others have mentioned, it leads to bitrot includes when formerly-needed symbols cease to be needed but the fact that a particular header is unnecessary goes unnoticed, and B) since many widely-used headers (at the very least, glibc and the Linux kernel) do not do this, it is not and cannot be arbitrarily made to be followed universally. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Fri, Aug 01, 2008 at 05:18:18PM -0400, The Wanderer wrote:
> Michael Niedermayer wrote:
>
> > On Fri, Aug 01, 2008 at 06:58:42AM -0400, The Wanderer wrote:
> >
> >> Michael Niedermayer wrote:
[...]
> > Theres a difference between
> > * every header musts somehow include its dependancies
>
> This is what I (currently believe I) am advocating.
and i do not oppose the rule of
"every header musts somehow include its dependancies"
>
> > * every header must directly include its dependancies
>
> This is something which I may have supported in the past, and may
> support again in the future, but am not presently terribly fond of.
this ("every header must directly include its dependancies")
is what i strongly oppose and what started this thread, peter removed
a #include "avcodec.h" because it was already included by audioconvert.h
and people started flaming about it ...
Besides this rule would lead to many more #include lines and consequently
many more passes over the file and could lead to a slowdown of the
compilation.
>
> > * no header should include any other header
>
> This implies "every source file should directly include every header
> file it needs", and I am not in favor of it at all. In theory, if
> followed universally, it could perhaps work; however, A) as I believe
> others have mentioned, it leads to bitrot includes when formerly-needed
> symbols cease to be needed but the fact that a particular header is
> unnecessary goes unnoticed, and B) since many widely-used headers (at
> the very least, glibc and the Linux kernel) do not do this, it is not
> and cannot be arbitrarily made to be followed universally.
The rule of including all things directly would likely lead to bitrot
as well for the same reasons as here.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:18:18PM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
Theres a difference between * every header musts somehow include its dependancies
This is what I (currently believe I) am advocating.
and i do not oppose the rule of "every header musts somehow include its dependancies"
* every header must directly include its dependancies
This is something which I may have supported in the past, and may support again in the future, but am not presently terribly fond of.
this ("every header must directly include its dependancies") is what i strongly oppose and what started this thread, peter removed a #include "avcodec.h" because it was already included by audioconvert.h and people started flaming about it ...
But he removed it from a .c file, not from a header. I suspect I believe that the two should not necessarily be treated the same way. My thoughts on this are (apparently) still evolving, but I think the central question here revolves around whether a given header file is *guaranteed*, either by documentation (or specification, etc.) or as a side effect of its own requirements, to need a given other header file - i.e., will audioconvert.h never cease to need some symbol from avcodec.h and thus need to include it, or may it potentially some day not need any such symbol and consequently cease to include that header? If the first header will inevitably include the second, then including the second while also including the first is redundant and inappropriate. If the first header may or may not include the second, then including both the second and the first is the appropriate thing to do. For the case of audioconvert.h and avcodec.h, that central question has not been answered AFAIK. I held the opinion that the removal made sense, because I also held an implicit assumption that audioconvert.h would inevitably need avcodec.h. If that is not the case, then I would agree that the removal should not have been done. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:18:18PM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
Theres a difference between * every header musts somehow include its dependancies
This is what I (currently believe I) am advocating.
and i do not oppose the rule of "every header musts somehow include its dependancies"
* every header must directly include its dependancies
This is something which I may have supported in the past, and may support again in the future, but am not presently terribly fond of.
this ("every header must directly include its dependancies") is what i strongly oppose and what started this thread, peter removed a #include "avcodec.h" because it was already included by audioconvert.h and people started flaming about it ...
But he removed it from a .c file, not from a header. I suspect I believe that the two should not necessarily be treated the same way.
My thoughts on this are (apparently) still evolving, but I think the central question here revolves around whether a given header file is *guaranteed*, either by documentation (or specification, etc.) or as a side effect of its own requirements, to need a given other header file - i.e., will audioconvert.h never cease to need some symbol from avcodec.h and thus need to include it, or may it potentially some day not need any such symbol and consequently cease to include that header?
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3. I do not know which is best, but IMO it does not matter, its a bikeshed issue whichever way is choosen the file will compile fine and in the rather unlikely case that avcodec.h is removed from audioconvert.h which would require the enums to be moved to a different header, its really just a 5sec job to fix the compilation failure of audioconvert.c
If the first header will inevitably include the second, then including the second while also including the first is redundant and inappropriate. If the first header may or may not include the second, then including both the second and the first is the appropriate thing to do.
For the case of audioconvert.h and avcodec.h, that central question has not been answered AFAIK. I held the opinion that the removal made sense, because I also held an implicit assumption that audioconvert.h would inevitably need avcodec.h. If that is not the case, then I would agree that the removal should not have been done.
The question is even more complex than this, because its debateable in how far audioconvert.c should include avcodec.h at all. avcodec.h is a big thing for libav Codec, audioconvert is no codec its a audio sample format converter that just needs avcodec.h because the sample format enum is in there ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 05:18:18PM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
Theres a difference between * every header musts somehow include its dependancies
This is what I (currently believe I) am advocating.
and i do not oppose the rule of "every header musts somehow include its dependancies"
* every header must directly include its dependancies
This is something which I may have supported in the past, and may support again in the future, but am not presently terribly fond of.
this ("every header must directly include its dependancies") is what i strongly oppose and what started this thread, peter removed a #include "avcodec.h" because it was already included by audioconvert.h and people started flaming about it ...
But he removed it from a .c file, not from a header. I suspect I believe that the two should not necessarily be treated the same way.
My thoughts on this are (apparently) still evolving, but I think the central question here revolves around whether a given header file is *guaranteed*, either by documentation (or specification, etc.) or as a side effect of its own requirements, to need a given other header file - i.e., will audioconvert.h never cease to need some symbol from avcodec.h and thus need to include it, or may it potentially some day not need any such symbol and consequently cease to include that header?
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;) it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h so strict direct inclusion rule would require for audioconvert.c (145 lines) #include "audioconvert.h" (the prototypes) #include "avcodec.h" (sample format enum) #include <stdio.h> (snprintf) #include "libavutil/mem.h" (av_free / av_malloc) #include <stdint.h> (uint8_t) #define _ISOC99_SOURCE #include <math.h> (lrintf) and the time finding this list took likely longer than all include bugfixes this file will ever need ... and id like to call attention to the fact that this is a 145 line file, i dont want to know how many includes would be needed for a 10 times larger file. If this system is applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting.
Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
But he removed it from a .c file, not from a header. I suspect I believe that the two should not necessarily be treated the same way.
My thoughts on this are (apparently) still evolving, but I think the central question here revolves around whether a given header file is *guaranteed*, either by documentation (or specification, etc.) or as a side effect of its own requirements, to need a given other header file - i.e., will audioconvert.h never cease to need some symbol from avcodec.h and thus need to include it, or may it potentially some day not need any such symbol and consequently cease to include that header?
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;)
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
so strict direct inclusion rule would require for audioconvert.c (145 lines) #include "audioconvert.h" (the prototypes) #include "avcodec.h" (sample format enum)
Actually, because audioconvert.h needs that same enum, unless I'm misremembering my C these two lines would have to come in the reverse order. Furthermore, I would say that because audioconvert.h will need that enum for just as long as audioconvert.c does, the include to support the enum should be in the header rather than in the .c file. (This means that if the enum does ever become unneeded but other things remained necessary, the include line would have to be moved from the header to the source file, which some might view as unnecessary churn.)
#include <stdio.h> (snprintf) #include "libavutil/mem.h" (av_free / av_malloc) #include <stdint.h> (uint8_t) #define _ISOC99_SOURCE #include <math.h> (lrintf)
The other things you list are more complicated. I think that strictly speaking, my position would indeed require that all of them be listed explicitly - *but* there is a way to avoid that. Nothing in my scheme requires that the header which directly defines a particular symbol be included directly; it is entirely acceptable to include any header which is guaranteed to pull in that definition by some means (this is exactly why including audioconvert.h would make it unnecessary to include avcodec.h for the enum). It would be possible to create a header file and say "this header file is guaranteed to always provide all of these commonly-needed external symbols" (and implement that by including various other headers), and then just include that file. Indeed, I sort of thought that that was exactly what common.h was for. This would have the downside of pulling in all of those symbols for things which need just a subset, but then that's a problem which applies to any header intended to be used in multiple files. I'm fairly sure there are problems with this which I haven't noticed; if anyone would care to present them, I could try to knock them down. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sat, Aug 02, 2008 at 08:24:27AM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
But he removed it from a .c file, not from a header. I suspect I believe that the two should not necessarily be treated the same way.
My thoughts on this are (apparently) still evolving, but I think the central question here revolves around whether a given header file is *guaranteed*, either by documentation (or specification, etc.) or as a side effect of its own requirements, to need a given other header file - i.e., will audioconvert.h never cease to need some symbol from avcodec.h and thus need to include it, or may it potentially some day not need any such symbol and consequently cease to include that header?
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;)
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
so strict direct inclusion rule would require for audioconvert.c (145 lines) #include "audioconvert.h" (the prototypes) #include "avcodec.h" (sample format enum)
Actually, because audioconvert.h needs that same enum, unless I'm misremembering my C these two lines would have to come in the reverse order.
no, audioconvert.h already incldues avcodec.h. the #include "avcodec.h" does nothing its just because the diego-mans rule says it should be there. The whole after all was an example of how it would look if the direct inclusion rule was followed strictly. And that implicates that all headers also directly include all their dependancies.
Furthermore, I would say that because audioconvert.h will need that enum for just as long as audioconvert.c does, the include to support the enum should be in the header rather than in the .c file. (This means that if
What diego and mans want is that the #include is both, in the c file as well as the header. Which is what iam opposing so strongly. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On Sat, Aug 02, 2008 at 05:33:50PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 08:24:27AM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
But he removed it from a .c file, not from a header. I suspect I believe that the two should not necessarily be treated the same way.
My thoughts on this are (apparently) still evolving, but I think the central question here revolves around whether a given header file is *guaranteed*, either by documentation (or specification, etc.) or as a side effect of its own requirements, to need a given other header file - i.e., will audioconvert.h never cease to need some symbol from avcodec.h and thus need to include it, or may it potentially some day not need any such symbol and consequently cease to include that header?
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;)
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
so strict direct inclusion rule would require for audioconvert.c (145 lines) #include "audioconvert.h" (the prototypes) #include "avcodec.h" (sample format enum)
Actually, because audioconvert.h needs that same enum, unless I'm misremembering my C these two lines would have to come in the reverse order.
no, audioconvert.h already incldues avcodec.h. the #include "avcodec.h" does nothing its just because the diego-mans rule says it should be there.
So far we have Mans, Baptiste and Diego in favor, with only you against.. Diego
On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:33:50PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 08:24:27AM -0400, The Wanderer wrote:
Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
But he removed it from a .c file, not from a header. I suspect I believe that the two should not necessarily be treated the same way.
My thoughts on this are (apparently) still evolving, but I think the central question here revolves around whether a given header file is *guaranteed*, either by documentation (or specification, etc.) or as a side effect of its own requirements, to need a given other header file - i.e., will audioconvert.h never cease to need some symbol from avcodec.h and thus need to include it, or may it potentially some day not need any such symbol and consequently cease to include that header?
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;)
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
so strict direct inclusion rule would require for audioconvert.c (145 lines) #include "audioconvert.h" (the prototypes) #include "avcodec.h" (sample format enum)
Actually, because audioconvert.h needs that same enum, unless I'm misremembering my C these two lines would have to come in the reverse order.
no, audioconvert.h already incldues avcodec.h. the #include "avcodec.h" does nothing its just because the diego-mans rule says it should be there.
So far we have Mans, Baptiste and Diego in favor, with only you against..
ehh? mans clearly said he considers common.h and internal.h as exceptions baptiste said he still has to think about if the #include of avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient And the wanderer clearly said he is against the include every header in every c and h file directly and redundantly. So while my proposal of no header includes another header has very few supporters, the extreem opposite you want has only yourself. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
On Sat, Aug 02, 2008 at 06:45:21PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:33:50PM +0200, Michael Niedermayer wrote:
no, audioconvert.h already incldues avcodec.h. the #include "avcodec.h" does nothing its just because the diego-mans rule says it should be there.
So far we have Mans, Baptiste and Diego in favor, with only you against..
ehh?
mans clearly said he considers common.h and internal.h as exceptions baptiste said he still has to think about if the #include of avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient And the wanderer clearly said he is against the include every header in every c and h file directly and redundantly.
So the Wanderer suddenly turned into an FFmpeg developer? My impression is that he just enjoys arguing for the sake of it. Which is bad, as it causes extra traffic and lengthens discussions considerably. Diego
On Sat, Aug 02, 2008 at 06:57:45PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:45:21PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:33:50PM +0200, Michael Niedermayer wrote:
no, audioconvert.h already incldues avcodec.h. the #include "avcodec.h" does nothing its just because the diego-mans rule says it should be there.
So far we have Mans, Baptiste and Diego in favor, with only you against..
ehh?
mans clearly said he considers common.h and internal.h as exceptions baptiste said he still has to think about if the #include of avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient And the wanderer clearly said he is against the include every header in every c and h file directly and redundantly.
So the Wanderer suddenly turned into an FFmpeg developer?
Right after you turned into a C developer. for non C see: r12427, r12424, r4447, r4371, r4369, r4366 He also very often helps with anything related to english grammer, the best way to say someting, ... And if he doesnt have a write account ATM id be happy to offer him one, or can you point to a single patch/change from him that would have been wrong?
My impression is that he just enjoys arguing for the sake of it. Which is bad, as it causes extra traffic and lengthens discussions considerably.
Anyone who does not happen to agree with you 100% should be lynched, i know. Pretty much noone agreed with my suggestion of "headers include no other headers" either and iam not asking anyone to better stay out of discussion because of that. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
On Sun, Aug 03, 2008 at 12:37:13PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:57:45PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:45:21PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:33:50PM +0200, Michael Niedermayer wrote:
no, audioconvert.h already incldues avcodec.h. the #include "avcodec.h" does nothing its just because the diego-mans rule says it should be there.
So far we have Mans, Baptiste and Diego in favor, with only you against..
ehh?
mans clearly said he considers common.h and internal.h as exceptions baptiste said he still has to think about if the #include of avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient And the wanderer clearly said he is against the include every header in every c and h file directly and redundantly.
So the Wanderer suddenly turned into an FFmpeg developer?
Right after you turned into a C developer.
Well, you wanted to invalidate my vote in MPlayer because you claimed I was not enough of a C developer. Surely I then have the same right to question the legitimacy of people participating in discussions, do I not?
for non C see: r12427, r12424, r4447, r4371, r4369, r4366
He also very often helps with anything related to english grammer, the best way to say someting, ...
I never doubted that.
And if he doesnt have a write account ATM id be happy to offer him one, or can you point to a single patch/change from him that would have been wrong?
He does not have a write account ATM.
My impression is that he just enjoys arguing for the sake of it. Which is bad, as it causes extra traffic and lengthens discussions considerably.
Anyone who does not happen to agree with you 100% should be lynched, i know.
Unlike you, I never asked for anybody to be lynched. Diego
On Sun, Aug 03, 2008 at 07:30:07PM +0200, Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 12:37:13PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:57:45PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:45:21PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:33:50PM +0200, Michael Niedermayer wrote:
no, audioconvert.h already incldues avcodec.h. the #include "avcodec.h" does nothing its just because the diego-mans rule says it should be there.
So far we have Mans, Baptiste and Diego in favor, with only you against..
ehh?
mans clearly said he considers common.h and internal.h as exceptions baptiste said he still has to think about if the #include of avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient And the wanderer clearly said he is against the include every header in every c and h file directly and redundantly.
So the Wanderer suddenly turned into an FFmpeg developer?
Right after you turned into a C developer.
Well, you wanted to invalidate my vote in MPlayer because you claimed I was not enough of a C developer.
I do remember claiming that you are not a C developer, i do not remember trying to invalidate anyones vote. Even less so do i remember any recent votes related to mplayer, Ive asked for one about the mplayer leadership situation but i do not remember that vote ever happening.
Surely I then have the same right to question the legitimacy of people participating in discussions, do I not?
yes, If you want to limit a vote about C code to people contributing to the C code or actively contributing to it that is fine. This would exclude the wanderer as well as you though.
for non C see: r12427, r12424, r4447, r4371, r4369, r4366
He also very often helps with anything related to english grammer, the best way to say someting, ...
I never doubted that.
And if he doesnt have a write account ATM id be happy to offer him one, or can you point to a single patch/change from him that would have been wrong?
He does not have a write account ATM.
Is this because he does not want one or because you do not want to give him one?
My impression is that he just enjoys arguing for the sake of it. Which is bad, as it causes extra traffic and lengthens discussions considerably.
Anyone who does not happen to agree with you 100% should be lynched, i know.
Unlike you, I never asked for anybody to be lynched.
I wouldnt have to ask if you would borrow me your bloody pitchfork once. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
Michael Niedermayer wrote:
On Sun, Aug 03, 2008 at 07:30:07PM +0200, Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 12:37:13PM +0200, Michael Niedermayer wrote:
And if he doesnt have a write account ATM id be happy to offer him one, or can you point to a single patch/change from him that would have been wrong?
He does not have a write account ATM.
Is this because he does not want one or because you do not want to give him one?
It's because, when we moved from CVS to SVN, I didn't feel that the time and attention I had to spare for the projects were enough to warrant going out of my way to get commit access back, and so far I seem to have been correct. I believe that Diego would indeed be willing to give me an account if I asked for one, but so far I have not. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:45:21PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
So far we have Mans, Baptiste and Diego in favor, with only you against..
ehh?
mans clearly said he considers common.h and internal.h as exceptions baptiste said he still has to think about if the #include of avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient And the wanderer clearly said he is against the include every header in every c and h file directly and redundantly.
So the Wanderer suddenly turned into an FFmpeg developer?
For the record, I never claimed to be one. I don't have any authority here, and I don't really expect to. I do, however, have a mind, and an interest in the issue, and therefore not unsurprisingly a desire to see it addressed. What you apparently interpret as "arguing for the sake of it" is, at least in this case, a manifestation of the way I approach figuring out (or otherwise trying to arrive at) answers on complicated issues, of which this almost unquestionably is one. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sun, Aug 03, 2008 at 07:14:48AM -0400, The Wanderer wrote:
Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:45:21PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
So far we have Mans, Baptiste and Diego in favor, with only you against..
ehh?
mans clearly said he considers common.h and internal.h as exceptions baptiste said he still has to think about if the #include of avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient And the wanderer clearly said he is against the include every header in every c and h file directly and redundantly.
So the Wanderer suddenly turned into an FFmpeg developer?
For the record, I never claimed to be one. I don't have any authority here, and I don't really expect to.
I do, however, have a mind, and an interest in the issue, and therefore not unsurprisingly a desire to see it addressed.
Fair enough. However, you do have a tendency to show up in discussions that have high flame and/or bikeshed potential. It is difficult enough to resolve such issues (and reach consensus) with few people involved. The more people take part, the harder it gets. If the people taking part in the discussion are not directly concerned with the issues at hand does not make things any easier.
What you apparently interpret as "arguing for the sake of it" is, at least in this case, a manifestation of the way I approach figuring out (or otherwise trying to arrive at) answers on complicated issues, of which this almost unquestionably is one.
You have said it yourself: Warning: Simply because I argue an issue does not mean I agree with any side of it. And I have seen you argue in such a fashion many times. You will have to forgive me if I sometimes cannot tell real concern, curiosity and arguing for the sake of arguing apart. Your contributions about English style and grammar are very much appreciated, as are any possible future contributions. Nonetheless, when you start playing an active role in flamewars, I feel you are stepping out of your territory. I know it is difficult to say this without being insulting, but this is my opinion and I know it is shared by at least Mans and Baptiste. best regards Diego
Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 07:14:48AM -0400, The Wanderer wrote:
Diego Biurrun wrote:
So the Wanderer suddenly turned into an FFmpeg developer?
For the record, I never claimed to be one. I don't have any authority here, and I don't really expect to.
I do, however, have a mind, and an interest in the issue, and therefore not unsurprisingly a desire to see it addressed.
Fair enough. However, you do have a tendency to show up in discussions that have high flame and/or bikeshed potential.
I'm aware of that. I think that it's probably because those are also the discussions which are complex enough, and require enough thought, for me to find them interesting.
It is difficult enough to resolve such issues (and reach consensus) with few people involved. The more people take part, the harder it gets. If the people taking part in the discussion are not directly concerned with the issues at hand does not make things any easier.
While I can see your point, I don't know if I entirely agree. Although there are exceptions, most of the time when I insert myself into these discussions, it is because either I think I see a possibly noteworthy perspective which does not appear to be being considered, or because I think I see a way to approach the matter which might be more helpful than what is already going on. Reaching consensus may indeed be more difficult with more people involved, but actually resolving the issue in a lasting fashion requires figuring out what the difficulty is at the root of the matter - and while adding more people does not particularly make that easier, adding another perspective - even, perhaps in some cases especially an uninvolved one - and/or changing the way the issue is being approached very much can.
What you apparently interpret as "arguing for the sake of it" is, at least in this case, a manifestation of the way I approach figuring out (or otherwise trying to arrive at) answers on complicated issues, of which this almost unquestionably is one.
You have said it yourself:
Warning: Simply because I argue an issue does not mean I agree with any side of it.
And I have seen you argue in such a fashion many times. You will have to forgive me if I sometimes cannot tell real concern, curiosity and arguing for the sake of arguing apart.
Noted and acknowledged. That warning is no longer as applicable as it once was, but it remains enough so that I have not removed it. I do not consider it to be as much a matter of "arguing for the sake of arguing" as "arguing because it seems to me that the argument needs to be made"; if there is a discussion going on and I see what seems to me to be an important point which is not being addressed, then even if I do not agree with that point, I will sometimes (less frequently now than was once the case) take it up simply so that it does not go unacknowledged. If it helps any, I do frequently (and not even always consciously) make a bit of a point to state "this is my opinion on this issue" in some paraphrase, as a way of indicating that I *do* agree with some side of that particular issue.
Your contributions about English style and grammar are very much appreciated, as are any possible future contributions. Nonetheless, when you start playing an active role in flamewars, I feel you are stepping out of your territory.
I acknowledge that I have gotten involved in flamewars around here in the past - the most recent which springs to mind being the Uoti clash. I also acknowledge that I have, for the most part, not been particularly helpful in those cases; in some instances I have come to regret getting involved at all. In this case, however, I do not see what I have posted as being actively flame-y; indeed I have sometimes gone out of my way to avoid attacks and insults when they might have been possible. I have, so far as I remember, remained focused on the issue itself, considering different possibilities and their consequences, attempting to explain (to myself as well as to others) the positions as I understand them and the problems involved with each. I may not have done that very well, but I would certainly not consider this to be one of my worse moments as far as arguments in these projects goes. I don't know that I consider the notion of "my territory" to be particularly applicable, so long as I am not attempting to say "because I object, it must not be done that way" - which, for the record, in this case I certainly am not; I do not work directly with the FFmpeg code, and my attempting to dictate how it must be arranged would not be appropriate. I have an opinion, and an interest, and in most cases am willing either to be persuaded to a different position or to shut up about it when another position prevails; so long as I do not attempt to dictate that my position be adhered to, I do not see why there would be anything wrong with my getting involved with any discussion to which I feel I have something to contribute.
I know it is difficult to say this without being insulting, but this is my opinion and I know it is shared by at least Mans and Baptiste.
I appreciate your letting me know that. (When people have a problem with me, I would much rather know it than either go on thinking they do not or think it is worse than it is.) I also appreciate your approaching this politely and calmly; I have had issues, not all that long ago, with people who did not. I would like to say that I take no insult from this, but I am not entirely sure that that is true. I can say, at the least, that I am not strongly offended by it, and that I will probably take it into account in future decisions. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
I know it is difficult to say this without being insulting, but this is my opinion and I know it is shared by at least Mans and Baptiste.
I appreciate your letting me know that. (When people have a problem with me, I would much rather know it than either go on thinking they do not or think it is worse than it is.) I also appreciate your approaching this politely and calmly; I have had issues, not all that long ago, with people who did not.
If I had any serious issues with you, you'd know it. Diego asked me on IRC what I thought of your contributions to various discussions, and I gave the honest answer that while I find your input on English style most helpful, your involvement in technical discussions can sometimes be distracting. I would have given the same reply, had the question been asked on the mailing list. Please, do not be offended. -- M?ns Rullg?rd mans at mansr.com
M?ns Rullg?rd wrote:
The Wanderer <inverseparadox at comcast.net> writes:
Diego Biurrun wrote:
I know it is difficult to say this without being insulting, but this is my opinion and I know it is shared by at least Mans and Baptiste.
I appreciate your letting me know that. (When people have a problem7 with me, I would much rather know it than either go on thinking they do not or think it is worse than it is.) I also appreciate your approaching this politely and calmly; I have had issues, not all that long ago, with people who did not.
If I had any serious issues with you, you'd know it. Diego asked me on IRC what I thought of your contributions to various discussions, and I gave the honest answer that while I find your input on English style most helpful, your involvement in technical discussions can sometimes be distracting. I would have given the same reply, had the question been asked on the mailing list. Please, do not be offended.
As I said (or tried to say), I am not, to any appreciable degree. Just because there is a problem does not mean that it is major, nor that it is necessarily appropriate to take offense regardless. I do also appreciate your stating this explicitly; I respect your opinion (though I do not always share it), and I will likely take this assessment into consideration in the future. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 07:14:48AM -0400, The Wanderer wrote:
What you apparently interpret as "arguing for the sake of it" is, at least in this case, a manifestation of the way I approach figuring out (or otherwise trying to arrive at) answers on complicated issues, of which this almost unquestionably is one.
You have said it yourself:
Warning: Simply because I argue an issue does not mean I agree with any side of it.
For the record, since omitting to mention it feels dishonest: what this originally referred to is the fact that I would sometimes see a discussion (or an argument) taking place, in which one or more positions which I felt were important were not being advocated by any side, and so would enter the discussion and argue one or more of those positions - whether or not I agreed with them - simply because I felt that the discussion could not be fully and comprehensively resolved without taking those positions into consideration. Admittedly these tended to be philosophical and/or theological arguments, and the same principle does not so easily apply to more technical discussions; that may well be part of why, as I said, this warning is no longer so applicable as once it was. I do, however, still do much the same thing from time to time. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sun, Aug 03, 2008 at 03:29:31PM -0400, The Wanderer wrote:
Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 07:14:48AM -0400, The Wanderer wrote:
What you apparently interpret as "arguing for the sake of it" is, at least in this case, a manifestation of the way I approach figuring out (or otherwise trying to arrive at) answers on complicated issues, of which this almost unquestionably is one.
You have said it yourself:
Warning: Simply because I argue an issue does not mean I agree with any side of it.
For the record, since omitting to mention it feels dishonest: what this originally referred to is the fact that I would sometimes see a discussion (or an argument) taking place, in which one or more positions which I felt were important were not being advocated by any side, and so would enter the discussion and argue one or more of those positions - whether or not I agreed with them - simply because I felt that the discussion could not be fully and comprehensively resolved without taking those positions into consideration.
Admittedly these tended to be philosophical and/or theological arguments, and the same principle does not so easily apply to more technical discussions; that may well be part of why, as I said, this warning is no longer so applicable as once it was. I do, however, still do much the same thing from time to time.
I just wanted to say that your arguments are very appreciated (at least by me, even if others disagree). And it would be sad if diego would scare you off the lists, your arguments did certainly sometimes point to interresting aspects that where not obvious (to me at least). An example of this surely where your arguments in the uoti flames. And arguments opposing ones own, are rarely "welcome" by that person. If he calls that person a troll, distracting or worse is more an indicator of that persons politeness than anyting else. Besides one cannot find a consensus if a significant portion of the people involved are prevented from participating in the discussions or scared away. That way one just finds his own oppinion, alone in an empty room ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
Michael Niedermayer wrote:
On Sun, Aug 03, 2008 at 03:29:31PM -0400, The Wanderer wrote:
Diego Biurrun wrote:
You have said it yourself:
Warning: Simply because I argue an issue does not mean I agree with any side of it.
For the record, since omitting to mention it feels dishonest: what this originally referred to is the fact that I would sometimes see a discussion (or an argument) taking place, in which one or more positions which I felt were important were not being advocated by any side, and so would enter the discussion and argue one or more of those positions - whether or not I agreed with them - simply because I felt that the discussion could not be fully and comprehensively resolved without taking those positions into consideration.
Admittedly these tended to be philosophical and/or theological arguments, and the same principle does not so easily apply to more technical discussions; that may well be part of why, as I said, this warning is no longer so applicable as once it was. I do, however, still do much the same thing from time to time.
I just wanted to say that your arguments are very appreciated (at least by me, even if others disagree). And it would be sad if diego would scare you off the lists,
There are, at least, no worries on this score. I have been subjected on occasion to significantly more direct, explicit and repeated offense in some other forums than anyone has ever offered me here, and I haven't left there yet either; the most I would be likely to do, if sufficiently pushed, would be to shut up for a while (and possibly stop reading the lists for long enough to recover emotional equilibrium, though I would catch up afterwards).
your arguments did certainly sometimes point to interresting aspects that where not obvious (to me at least). An example of this surely where your arguments in the uoti flames.
Thank you; that is what I aim for in doing interjecting that way (and was hoping for in the specific posts I think you're referring to), and I don't feel that I succeed nearly as often as I'd like.
And arguments opposing ones own, are rarely "welcome" by that person. If he calls that person a troll, distracting or worse is more an indicator of that persons politeness than anyting else.
I don't know if I'd go that far. I can certainly see how in some cases I could be said to have failed to contribute anything worthwhile, and indeed to have in the end been no more than a distraction from what the end result wound up being. Those are, however, most often simply the cases where I failed in my intent; I'll be one of the first to admit that my skills at expressing my thoughts clearly are not always remotely what they should be.
Besides one cannot find a consensus if a significant portion of the people involved are prevented from participating in the discussions or scared away. That way one just finds his own oppinion, alone in an empty room ...
This is true. The obvious counterargument in at least this case would be that I'm not actually involved, just interested; that doesn't make it any less true, nor does it necessarily mean that I should keep out of things, but it is a point worth keeping in mind nonetheless. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;)
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
These definitions are part of the global CFLAGS, no need to duplicate them. Diego
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;)
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
These definitions are part of the global CFLAGS, no need to duplicate them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is not what we do, but why we do it that matters.
On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote:
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
Those are standard C, so any special defines are only required if the default is to use old versions.
These definitions are part of the global CFLAGS, no need to duplicate them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them.
MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for standard C functions. So even if such defines are not set any problems could only occur if you're using some compiler which MPlayer does not recognize and which does not support C99 functions by default.
On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote:
On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote:
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
Those are standard C, so any special defines are only required if the default is to use old versions.
no ------- Linux Programmer?s Manual LRINT(3) NAME lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer SYNOPSIS [...] Link with -lm. Feature Test Macro Requirements for glibc (see feature_test_macros(7)): All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------
These definitions are part of the global CFLAGS, no need to duplicate them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them.
MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for standard C functions. So even if such defines are not set any problems could only occur if you're using some compiler which MPlayer does not recognize and which does not support C99 functions by default.
see above, the manual page of lrintf explain it rather clearly, what is needed on linux. I do not know if you propose to drop linux support or if you propose to depend on undocumented options. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote:
On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote:
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
Those are standard C, so any special defines are only required if the default is to use old versions.
no ------- Linux Programmer?s Manual LRINT(3)
NAME lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer
SYNOPSIS [...] Link with -lm.
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------
These definitions are part of the global CFLAGS, no need to duplicate them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them.
MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for standard C functions. So even if such defines are not set any problems could only occur if you're using some compiler which MPlayer does not recognize and which does not support C99 functions by default.
see above, the manual page of lrintf explain it rather clearly, what is needed on linux. I do not know if you propose to drop linux support or if you propose to depend on undocumented options.
-std=gnu99 is a superset of -std=c99, so no problem. Diego
On Sat, Aug 02, 2008 at 06:15:20PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote:
On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote:
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
Those are standard C, so any special defines are only required if the default is to use old versions.
no ------- Linux Programmer?s Manual LRINT(3)
NAME lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer
SYNOPSIS [...] Link with -lm.
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------
These definitions are part of the global CFLAGS, no need to duplicate them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them.
MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for standard C functions. So even if such defines are not set any problems could only occur if you're using some compiler which MPlayer does not recognize and which does not support C99 functions by default.
see above, the manual page of lrintf explain it rather clearly, what is needed on linux. I do not know if you propose to drop linux support or if you propose to depend on undocumented options.
-std=gnu99 is a superset of -std=c99, so no problem.
The manual disagrees with you, it lists _XOPEN_SOURCE, _ISOC99_SOURCE and -std=c99 it does not list gnu99 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle
On Sat, Aug 02, 2008 at 06:32:36PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:15:20PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote:
On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote: > it also uses lrintf & snprintf thus also needs one way or another > stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before > inclusion of math.h
Those are standard C, so any special defines are only required if the default is to use old versions.
no ------- Linux Programmer?s Manual LRINT(3)
NAME lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer
SYNOPSIS [...] Link with -lm.
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------
These definitions are part of the global CFLAGS, no need to duplicate them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them.
MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for standard C functions. So even if such defines are not set any problems could only occur if you're using some compiler which MPlayer does not recognize and which does not support C99 functions by default.
see above, the manual page of lrintf explain it rather clearly, what is needed on linux. I do not know if you propose to drop linux support or if you propose to depend on undocumented options.
-std=gnu99 is a superset of -std=c99, so no problem.
The manual disagrees with you, it lists _XOPEN_SOURCE, _ISOC99_SOURCE and -std=c99 it does not list gnu99
You are reading the wrong manual. The gcc manual clearly states that gnu99 is a superset of c99. Diego
On Sat, Aug 02, 2008 at 06:46:08PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:32:36PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:15:20PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote:
On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote: > On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote: > > it also uses lrintf & snprintf thus also needs one way or another > > stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before > > inclusion of math.h
Those are standard C, so any special defines are only required if the default is to use old versions.
no ------- Linux Programmer?s Manual LRINT(3)
NAME lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer
SYNOPSIS [...] Link with -lm.
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------
> These definitions are part of the global CFLAGS, no need to duplicate > them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them.
MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for standard C functions. So even if such defines are not set any problems could only occur if you're using some compiler which MPlayer does not recognize and which does not support C99 functions by default.
see above, the manual page of lrintf explain it rather clearly, what is needed on linux. I do not know if you propose to drop linux support or if you propose to depend on undocumented options.
-std=gnu99 is a superset of -std=c99, so no problem.
The manual disagrees with you, it lists _XOPEN_SOURCE, _ISOC99_SOURCE and -std=c99 it does not list gnu99
You are reading the wrong manual. The gcc manual clearly states that gnu99 is a superset of c99.
gcc is a c library? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
On Sat, Aug 02, 2008 at 06:47:06PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:46:08PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:32:36PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:15:20PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote:
On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote: > On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote: > > On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote: > > > it also uses lrintf & snprintf thus also needs one way or another > > > stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before > > > inclusion of math.h
Those are standard C, so any special defines are only required if the default is to use old versions.
no ------- Linux Programmer?s Manual LRINT(3)
NAME lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer
SYNOPSIS [...] Link with -lm.
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------
> > These definitions are part of the global CFLAGS, no need to duplicate > > them. > > until it causes you an hour of work when you try to compile it > in mplayer that happenes not to set them.
MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for standard C functions. So even if such defines are not set any problems could only occur if you're using some compiler which MPlayer does not recognize and which does not support C99 functions by default.
see above, the manual page of lrintf explain it rather clearly, what is needed on linux. I do not know if you propose to drop linux support or if you propose to depend on undocumented options.
-std=gnu99 is a superset of -std=c99, so no problem.
The manual disagrees with you, it lists _XOPEN_SOURCE, _ISOC99_SOURCE and -std=c99 it does not list gnu99
You are reading the wrong manual. The gcc manual clearly states that gnu99 is a superset of c99.
gcc is a c library?
I have no idea what silly game you are trying to play here, but you quoted above (linebreak mine): All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^ Since -std=gnu99 is a superset of -std=c99, we are safe. Diego
.On Sat, Aug 02, 2008 at 07:00:02PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:47:06PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:46:08PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:32:36PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:15:20PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote: > On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote: > > On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote: > > > On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote: > > > > it also uses lrintf & snprintf thus also needs one way or another > > > > stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before > > > > inclusion of math.h > > Those are standard C, so any special defines are only required if the > default is to use old versions.
no ------- Linux Programmer?s Manual LRINT(3)
NAME lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer
SYNOPSIS [...] Link with -lm.
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ------- > > > These definitions are part of the global CFLAGS, no need to duplicate > > > them. > > > > until it causes you an hour of work when you try to compile it > > in mplayer that happenes not to set them. > > MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for > standard C functions. So even if such defines are not set any problems > could only occur if you're using some compiler which MPlayer does not > recognize and which does not support C99 functions by default.
see above, the manual page of lrintf explain it rather clearly, what is needed on linux. I do not know if you propose to drop linux support or if you propose to depend on undocumented options.
-std=gnu99 is a superset of -std=c99, so no problem.
The manual disagrees with you, it lists _XOPEN_SOURCE, _ISOC99_SOURCE and -std=c99 it does not list gnu99
You are reading the wrong manual. The gcc manual clearly states that gnu99 is a superset of c99.
gcc is a c library?
I have no idea what silly game you are trying to play here, but you quoted above (linebreak mine):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^
Since -std=gnu99 is a superset of -std=c99, we are safe.
tcc gnu99test.c -o gnu99test -std=gnu99 tcc: invalid option -- '-std=gnu99' now, i know you will tell me that you check for gnu99 support in mplayer and omit "-std=gnu99" if the compiler fails to compile with it. But when you omit it, it no longer is a superset of c99 and you no longer follow the libc docs requirement of _ISOC99_SOURCE || _XOPEN_SOURCE >= 600 of course compilers might enable these defines by default but thats a gamble. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates
On Sun, Aug 03, 2008 at 01:17:06PM +0200, Michael Niedermayer wrote:
.On Sat, Aug 02, 2008 at 07:00:02PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:47:06PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:46:08PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:32:36PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:15:20PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote: > On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote: > > On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote: > > > On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote: > > > > On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote: > > > > > it also uses lrintf & snprintf thus also needs one way or another > > > > > stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before > > > > > inclusion of math.h > > > > Those are standard C, so any special defines are only required if the > > default is to use old versions. > > no > ------- > Linux Programmer?s Manual LRINT(3) > > NAME > lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer > > SYNOPSIS > [...] > Link with -lm. > > Feature Test Macro Requirements for glibc (see feature_test_macros(7)): > > All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ------- > > > > These definitions are part of the global CFLAGS, no need to duplicate > > > > them. > > > > > > until it causes you an hour of work when you try to compile it > > > in mplayer that happenes not to set them. > > > > MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for > > standard C functions. So even if such defines are not set any problems > > could only occur if you're using some compiler which MPlayer does not > > recognize and which does not support C99 functions by default. > > see above, the manual page of lrintf explain it rather clearly, what is > needed on linux. I do not know if you propose to drop linux support or > if you propose to depend on undocumented options.
-std=gnu99 is a superset of -std=c99, so no problem.
The manual disagrees with you, it lists _XOPEN_SOURCE, _ISOC99_SOURCE and -std=c99 it does not list gnu99
You are reading the wrong manual. The gcc manual clearly states that gnu99 is a superset of c99.
gcc is a c library?
I have no idea what silly game you are trying to play here, but you quoted above (linebreak mine):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^
Since -std=gnu99 is a superset of -std=c99, we are safe.
tcc gnu99test.c -o gnu99test -std=gnu99 tcc: invalid option -- '-std=gnu99'
Does tcc understand -std=c99?
now, i know you will tell me that you check for gnu99 support in mplayer and omit "-std=gnu99" if the compiler fails to compile with it.
Yes, of course the option is checked for, though only in the gcc case. What exactly was the point you were trying to make here?
But when you omit it, it no longer is a superset of c99 and you no longer follow the libc docs requirement of _ISOC99_SOURCE || _XOPEN_SOURCE >= 600 of course compilers might enable these defines by default but thats a gamble.
Support for other compilers in MPlayer is embryonic at best and the whole compiler option handling in MPlayer's configure is in for an overhaul... Diego
On Sun, Aug 03, 2008 at 01:45:06PM +0200, Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 01:17:06PM +0200, Michael Niedermayer wrote:
.On Sat, Aug 02, 2008 at 07:00:02PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:47:06PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:46:08PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 06:32:36PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 06:15:20PM +0200, Diego Biurrun wrote: > On Sat, Aug 02, 2008 at 05:54:56PM +0200, Michael Niedermayer wrote: > > On Sat, Aug 02, 2008 at 06:40:13PM +0300, Uoti Urpala wrote: > > > On Sat, 2008-08-02 at 17:23 +0200, Michael Niedermayer wrote: > > > > On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote: > > > > > On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote: > > > > > > it also uses lrintf & snprintf thus also needs one way or another > > > > > > stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before > > > > > > inclusion of math.h > > > > > > Those are standard C, so any special defines are only required if the > > > default is to use old versions. > > > > no > > ------- > > Linux Programmer?s Manual LRINT(3) > > > > NAME > > lrint, lrintf, lrintl, llrint, llrintf, llrintl - round to nearest integer > > > > SYNOPSIS > > [...] > > Link with -lm. > > > > Feature Test Macro Requirements for glibc (see feature_test_macros(7)): > > > > All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ------- > > > > > These definitions are part of the global CFLAGS, no need to duplicate > > > > > them. > > > > > > > > until it causes you an hour of work when you try to compile it > > > > in mplayer that happenes not to set them. > > > > > > MPlayer uses -std=gnu99 with GCC, so no extra defines are needed for > > > standard C functions. So even if such defines are not set any problems > > > could only occur if you're using some compiler which MPlayer does not > > > recognize and which does not support C99 functions by default. > > > > see above, the manual page of lrintf explain it rather clearly, what is > > needed on linux. I do not know if you propose to drop linux support or > > if you propose to depend on undocumented options. > > -std=gnu99 is a superset of -std=c99, so no problem.
The manual disagrees with you, it lists _XOPEN_SOURCE, _ISOC99_SOURCE and -std=c99 it does not list gnu99
You are reading the wrong manual. The gcc manual clearly states that gnu99 is a superset of c99.
gcc is a c library?
I have no idea what silly game you are trying to play here, but you quoted above (linebreak mine):
All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99 ^^^^^^^^^^^
Since -std=gnu99 is a superset of -std=c99, we are safe.
tcc gnu99test.c -o gnu99test -std=gnu99 tcc: invalid option -- '-std=gnu99'
Does tcc understand -std=c99?
not the version i have, but it does understand -D_ISOC99_SOURCE
now, i know you will tell me that you check for gnu99 support in mplayer and omit "-std=gnu99" if the compiler fails to compile with it.
Yes, of course the option is checked for, though only in the gcc case.
What exactly was the point you were trying to make here?
That mplayer depends on C99 functions but does not #define _ISOC99_SOURCE as glibc requires. This is not an argument for or against -std=gnu99 just that no matter if it is there, -D_ISOC99_SOURCE still has to be there. And i think even uoti will agree about this. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
On Sun, Aug 03, 2008 at 05:13:18PM +0200, Michael Niedermayer wrote:
On Sun, Aug 03, 2008 at 01:45:06PM +0200, Diego Biurrun wrote:
On Sun, Aug 03, 2008 at 01:17:06PM +0200, Michael Niedermayer wrote:
What exactly was the point you were trying to make here?
That mplayer depends on C99 functions but does not #define _ISOC99_SOURCE as glibc requires.
This is not an argument for or against -std=gnu99 just that no matter if it is there, -D_ISOC99_SOURCE still has to be there. And i think even uoti will agree about this.
Why not start out constructive in the first place? As I said, MPlayer's setting of compiler flags needs to be overhauled. Diego
On Sat, Aug 02, 2008 at 05:23:59PM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 02:50:40PM +0200, Diego Biurrun wrote:
On Sat, Aug 02, 2008 at 04:25:52AM +0200, Michael Niedermayer wrote:
On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
currently audioconvert.h needs the audio sample format enum and audioconvert.c needs it too, and its provided by avcodec.h after a 5 sec look, audioconvert.c also use av_free() and uint8_t at that point one can start a long discussion if stdint.h and mem.h should be included or avcodec.h or nothing or all 3.
after a little longer ;)
it also uses lrintf & snprintf thus also needs one way or another stdio.h and math.h with _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE defined before inclusion of math.h
These definitions are part of the global CFLAGS, no need to duplicate them.
until it causes you an hour of work when you try to compile it in mplayer that happenes not to set them.
:) I intend to separate FFmpeg's and MPlayer's configuration one day - for a very good reason.. Diego
compn wrote:
On Thu, 31 Jul 2008 16:32:20 +0200, Aurelien Jacobs wrote:
Not only unnecessary, but even bad. The usage here is that every file must include every headers that it requires directly. You should not rely on one header including another (except when it's explicitely documented so, such as inttypes.h including stdint.h). So here you should add back the avcodec.h include.
is this policy documented somewhere?
In the mailing list archives... ;-) More seriously, that's indeed the kind of thing which would need to be written somewhere in the doc. Do you volunteer ? Aurel
pross at xvid.org wrote:
On Thu, Jul 31, 2008 at 03:35:05PM +0200, Benoit Fouet wrote:
pross wrote:
Modified: trunk/libavcodec/audioconvert.c ============================================================================== --- trunk/libavcodec/audioconvert.c (original) +++ trunk/libavcodec/audioconvert.c Thu Jul 31 14:55:06 2008 @@ -25,7 +25,49 @@ * @author Michael Niedermayer <michaelni at gmx.at> */
-#include "avcodec.h"
why did you remove this one ? isn't it needed by the file ?
avcodec.h is provided by audioconvert.h.
Indeed, this change was unnecessary and could have been comitted later, seperately. I'll avoid such changes in future...
It should not be committed at all. Files should #include all headers they explicitly depend on. The only exceptions to this rule are common.h and internal.h. Please revert this. -- M?ns Rullg?rd mans at mansr.com
participants (14)
-
aurel＠gnuage.org -
banan＠ludd.ltu.se -
benoit.fouet＠purplelabs.com -
diego＠biurrun.de -
ikalvachev＠gmail.com -
inverseparadox＠comcast.net -
mans＠mansr.com -
michaelni＠gmx.at -
mike＠multimedia.cx -
pross＠xvid.org -
robert.swain＠gmail.com -
subversion＠mplayerhq.hu -
tempn＠twmi.rr.com -
uoti.urpala＠pp1.inet.fi