[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Uoti Urpala]

On Wed, 2006-09-20 at 09:46 -0400, Rich Felker wrote:
> On Wed, Sep 20, 2006 at 08:47:40AM +0300, Uoti Urpala wrote:
> > The C language spec isn't even meant to cover everything relevant to
> > creating real programs.
> 
> The _language_ is, just not the standard library. You never need a
> construct that is not valid C to write real programs. On the other

So you don't need to write code that is not standard C, you just include
or link it from a library. At least if you can get someone else to write
the library.

> hand, POSIX does cover everything relevant to creating real programs
> and also (quite wisely) does not specify such nonsense as visibility
> because it's a _language_ issue. Making it an OS issue is a misguided

So here you say visibility is a language issue...

> This statement is utterly stupid. Visibility is outside the scope of
> C, just like threads and processes and filesystem structure is outside
> the scope of C, and just like digital storage units are outside the

... and here you say it's outside the scope of C. I'm not sure what kind
of definitions you'd need to use for "language issue" and "scope of C"
for these statements to make sense.

A compiler does need to be aware of dynamic linking and visibility (or
specifically whether the symbol is in the same shared object) because it
affects how the symbols must be accessed. It's possible to use just a
single -fpic compiler switch instead of per-symbol information, but then
the compiler must assume the most expensive way to access all external
symbols. And this is not the fault of ELF, any shared object system
which doesn't modify the code at linktime would share those issues.