change log for rtems (2011-02-24)

[Ralf Corsepius]

On 02/25/2011 06:52 PM, Gedare Bloom wrote:
> On Fri, Feb 25, 2011 at 11:13 AM, Ralf Corsepius
> <ralf.corsepius at rtems.org>  wrote:
>> On 02/25/2011 12:26 PM, Chris Johns wrote:
>>>
>>> On 25/02/11 9:25 PM, Ralf Corsepius wrote:
>>>>
>>>> And I don't share this view and fail to understand why you and Chris are
>>>> complaining.
>>>
>>> I was not complaining. Rather I was just understanding the reason so I
>>> can determine if I need to be doing something more when I add code like
>>> this in the future.
>>
>> As I tried to explain before, it's
>> * in first place "code clarity" (e.g. when grepping the code when going
>> after questions like "where is the declaration/definion", what may be the
>> cause of the symbol-clash, what is the reason for this "cryptic linker
>> error" etc.)
> Not really, because it is common for the non-extern declaration
> (prototype) to be in a header file, e.g. statvfs.h, and the associated
> definition (body) to be in a C file, e.g. statvfs.c. Seeing it
> declared extern in a header file would make me think it is in some
> other file "namespace" so to speak.
I don't understand what you are trying to say.

>> and
>> * in second place avoiding conflicts (e.g. when a file contains a local
>> "static foo()" and misses to include the global header, when the global
>> header wants "extern foo()", ...).
>>
> Not sure I understand the example/use case you propose. If the header
> is missed, it doesn't matter how the function is declared.

It matters when the code changes.

  If the
> header is included, it will complain that the static definition
> follows non-static declaration. I just don't see any savings here for
> avoiding conflicts. Maybe if you can give a concise and reasonable
> example for why this change affects correctness the argument will go
> away.


>> Another (hardly relevant to RTEMS) issue would be interfacing with C++,
>> which implictily treats functions without "extern" (and without "extern C")
>> as static.
>>
> Well, since we already have to wrap all headers with extern C, this is
> a non-issue.
>
> I don't really agree with the convention that all headers should
> declare all functions as extern, but it should be decided one way or
> another to prevent future confusion on whether it is a convention or
> not.  This does seem like a "whitespace" type of issue, since it does
> not AFAIK affect any program correctness.

Do I have to emphasize what I think about this thread?

Folks, wake up, this is 2011 and not 1989 ... if we are interested in 
writing modern code, we should do so ...

Have a look into glibc and into gcc and you'll likely be surprised how 
modern code looks like.