«

On Mar 26, 9:13 am, jacob navia <ja...@nospam.com> wrote:
> And there are worst things that can be done:
> file1.c:
> int buf[256];
>
> file2.c:
>
> int buff[512];
>
> The linker will leave 'buf' in the common section, but will set its size
> to the bigger value, i.e. 512. This is harmless, but beware that you
> make a definition in a file3.c
>
> int buff[4] = {0,0,0,0};
>
> Your table will have a size of just four positions instead of 512!!
>
> This can be tested, for instance, with the following two files:
> file t1.c
> int tab[12];
>
> File t2.c
> int tab[256];
> int main(void){return 0;}
>
> Linking t1.c and t2.c with MSVC 8 we obtain an executable *without any
> warnings* not even at the highest warning level.


This is one of the many good reason to use lint. And an area where C+
+ is arguably a "better C" than C.

"Ben Bacarisse" <> wrote in message
news:...
> jacob navia <> writes:
> <snip>
>> This can be tested, for instance, with the following two files:
>> file t1.c
>> int tab[12];
>>
>> File t2.c
>> int tab[256];
>> int main(void){return 0;}
>>
>> Linking t1.c and t2.c with MSVC 8 we obtain an executable *without any
>> warnings* not even at the highest warning level.
>>
>> In the linker of lcc-win I added a warning:
>> in t1.obj warning: '_tab' (defined with size 4
>> is redefined in t2.obj with size 1024
>>
>> The linker of gnu doesn't emit any warning:
>> root@ubuntu:/tmp# gcc -Wall t1.c t2.c
>
> *Please* post these articles in comp.programming. I'd join in a lot
> more if I could do so and be topical. However, you are dead set on
> knocking gcc without understanding it so...
>
> <off-topic>
> gcc uses the GNU linker ld. ld merges the common blocks to make tab
> the larger of the two size regardless of the linking order. In this
> case, I can't see why you'd want a diagnostic[1]. When a compilation
> unit initialises the table (so it can't be merged) the GNU linker
> *does* produce a warning:
>
> /usr/bin/ld: Warning: size of symbol `tab' changed from 1024 in t1.o
> to 16 in t2.o
> </off-topic>
>
> <snip>
>> Next installment will treat the object libraries
>
> Please post it where it belongs.
>
> [1] OK, a case can be made for a diagnostic in all such cases, but you
> are suggesting the gcc leads the programmer silently into a trap.

C:\tmp>splint t1.c t2.c
Splint 3.1.1 --- 12 Mar 2007

t2.c(2,5): Variable tab redefined
A function or variable is redefined. One of the declarations should use
extern. (Use -redef to inhibit warning)
t1.c(2,5): Previous definition of tab

Finished checking --- 1 code warning

C:\tmp>lin t1.c t2.c

C:\tmp>"C:\Lint\Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP) t1.c t2.c
PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software 1985-2006

--- Module: t1.c (C)

--- Module: t2.c (C)

C:\tmp>type _LINT.TMP | more

--- Module: t1.c (C)

--- Module: t2.c (C)
_
int tab[256];
t2.c(2) : Error 18: Symbol 'tab' redeclared (size) conflicts with line 2,
file
t1.c
t1.c(2) : Info 830: Location cited in prior message
_
int tab[256];
t2.c(2) : Error 14: Symbol 'tab' previously defined (line 2, file t1.c)
t1.c(2) : Info 830: Location cited in prior message

--- Global Wrap-up

Info 765: external 'tab' (line 2, file t1.c) could be made static
t1.c(2) : Info 830: Location cited in prior message
Warning 552: Symbol 'tab' (line 2, file t1.c) not accessed
t1.c(2) : Info 830: Location cited in prior message

---
output placed in _LINT.TMP

C:\tmp>type t1.c
/* file t1.c */
int tab[12];


C:\tmp>type t2.c
/* File t2.c */
int tab[256];
int main(void){tab[25] = 0; return 0;}

P.S.
There are plenty of instances of undefined behavior not caught by compilers.
P.P.S.
I do agree that it would be nice if compilers were omniscient (or closer
than they are today).



--
Posted via a free Usenet account from http://www.teranews.com

On 26 Mar 2008 at 15:40, wrote:
> On Mar 26, 4:13 pm, jacob navia <ja...@nospam.com> wrote:
><big article about linkers, assembly & others>
> What's the actual intent behind these posts?
> Bring revolution to clc & usenet? Inform poor souls that figured out
> how to browse clc but not other groups? Bring more noise & trolls?
> Annoy the "no stack in C" people?

This post really tells you all you need to know about clc. You're
expected to justify yourself for posting an informative article about an
essential part of C programming.

Will the madness end one day?

Kaz Kylheku wrote:
> On Mar 26, 10:22 am, jacob navia <ja...@nospam.com> wrote:
>> Kaz Kylheku wrote:
>>>> And there are worst things that can be done:
>>>> file1.c:
>>>> int buf[256];
>>>> file2.c:
>>>> int buff[512];
>>>> The linker will leave 'buf' in the common section, but will set its size
>>>> to the bigger value, i.e. 512.
>>> Not any linker that anyone in his right mind would be writing today.
>> I showed that both MSVC and GCC/GNU linkers accept this without
>> warnings.
>
> Ah yes. The combination of GNU C and the GNU linker won't accept it
> if the arrays have initializers. This is true even if the initializers
> are { 0 }.
>
> Unlike what you said, it's not the linker that determines the
> assignment of the symbol to the section.

I did not said that. The linker just uses the definitions
in the object file of course, and that is generated by the
compiler. Just a misunderstanding.

> This is done by the compiler,
> which emits pseudo-ops in the assembly output that control sectioning.
>

Yes, and those go into the object file.

> Tentative definitions are placed, by the gcc, into a section
> called .comm, which is subject to special semantics purely for
> backward compatibility with ancient programs which rely on that model.
>

Like lcclnk, and MSVC.


> However, normal definitions are placed into .bss.
>
> The GNU linker has an option --warn-common which will diagnose the
> merging of symbols in the common section.
>
> So if you compile with:
>
> gcc -Wl,--warn-common
>
> the link succeeds, but you get a diagnostic.
>

Interesting. I did not know that option, maybe it should
be make the default?


> Maybe the compiler itself can be coaxed into not doing the common
> allocation in the first place. Aha, yes, the -fno-common option!
>
> gcc -fno-common ...
>

OK.

> Now the tentative definitions behave just like normal definitions, and
> the link fails.
>
> This is what C says: by the end of a translation unit, a tentative
> definition becomes a fully fledged definition, is if with a zero
> initializer. It does not remain some kind of second-class citizen.
>

But most linkers do not use that in their default state, as you have
seen. I think this is a flaw in the language. It should specifically
forbid that.

> It's somewhat braindamaged that -fno-common isn't the default.

Agreed!

> The
> backward compatibility behavior should be explicitly requested with -
> fcommon. Uninitialized definitions should go into .bss by default,
> not .comm.
>
> I'm going to patch this in the Linux distro that I maintain, to see
> what breaks. I'm guessing that quite a few things, because any time a
> programmer forgets to use ``extern'' in a header file declaration, and
> include the header in two or more translation unit, you're going to
> run into this.
>
> It would be reasonable for -ansi -pedantic to imply -fno-common.

I think that the language should specify this. It is a flaw of the
language.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Dann Corbit wrote:

[snip example of lint]

>
> P.S.
> There are plenty of instances of undefined behavior not caught by compilers.
> P.P.S.
> I do agree that it would be nice if compilers were omniscient (or closer
> than they are today).

You are right about lint. It is a useful tool. But the problem is in the
language, and specifically in the language standard. It doesn't specify
this, and allows this behavior.

This should be corrected at the language level, in my opinion.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Flash Gordon wrote:
> jacob navia wrote, On 26/03/08 16:21:
>> This is a common error, that provokes no warnings.
>
> On some implementations. On others it produces an error. It would be
> more useful to simply tell people how to get there implementation to
> produce an error for it. The implementations that I know for a fact will
> produce an error are gcc/GNU ld under Linux when given specific options,
> I believe you can get the same behaviour on AIX and SCO.
>

I think that this is a flaw of the language specifications. This should
be forbidden. But somehow the standards left this out for political
(or whatever) reasons. It is a mistake.

Can you name an implementation that produces an error (without
any extra obscure options) ?

>> I wanted to
>> discuss this state of affairs.
>
> It does not need masses of information about linkers to discus it and
> the problem is not specific to C.
>

Well, I wanted to explain linking and the associated problems.
This is a group about C and I do not see C without the link
step, sorry (C interpreters are not the main usage of C)

>> Read the article before you say something about it.
>
> Try posting it to somewhere it is topical such as comp.programming. Are
> you fundamentally unable to understand the concept of topicality or you
> simply trolling?

To say that this essential step of all C programs is "Off topic"
is an abomination really. Even the C standard mentions the linker
so please...


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

wrote:
>
> This is one of the many good reason to use lint. And an area where C+
> + is arguably a "better C" than C.


Why not c hanged it and specify the linker model correctly?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia <> wrote:
>
> You are right about lint. It is a useful tool. But the problem is in the
> language, and specifically in the language standard. It doesn't specify
> this, and allows this behavior.

No, it doesn't, it tars and feathers it as "undefined behavior", which
is hardly allowing it. It just doesn't require the compiler to diagnose
it (since it can't with separate compilation) and it can't require the
linker to diagnose it since that's out of scope. (On most systems, the
linker is a separate product, not tied to any particular language. And
the choice of which linkage model to use is frequently affected by
inter-language compatibility concerns.)

-Larry Jones

Even if lives DID hang in the balance, it would depend on whose they were.
-- Calvin

jacob navia wrote, On 26/03/08 20:14:
> Flash Gordon wrote:
>> jacob navia wrote, On 26/03/08 16:21:
>>> This is a common error, that provokes no warnings.
>>
>> On some implementations. On others it produces an error. It would be
>> more useful to simply tell people how to get there implementation to
>> produce an error for it. The implementations that I know for a fact
>> will produce an error are gcc/GNU ld under Linux when given specific
>> options, I believe you can get the same behaviour on AIX and SCO.
>>
>
> I think that this is a flaw of the language specifications. This should
> be forbidden. But somehow the standards left this out for political
> (or whatever) reasons. It is a mistake.

Well, changes to the language specification belong in comp.std.c, but in
any case it does not need going in to details about the linker.

> Can you name an implementation that produces an error (without
> any extra obscure options) ?

Define an obscure option. However, I believe the TI TMS320C2xx
compiler/assembler/linker would qualify since it does not have (as far
as I remember or can see in the documentation) a common section.

>>> I wanted to
>>> discuss this state of affairs.
>>
>> It does not need masses of information about linkers to discus it and
>> the problem is not specific to C.
>
> Well, I wanted to explain linking and the associated problems.
> This is a group about C and I do not see C without the link
> step, sorry (C interpreters are not the main usage of C)

The details you provide are not needed to discus the issue and are not
universally correct even if you ignore interpreters.

>>> Read the article before you say something about it.
>>
>> Try posting it to somewhere it is topical such as comp.programming.
>> Are you fundamentally unable to understand the concept of topicality
>> or you simply trolling?
>
> To say that this essential step of all C programs is "Off topic"
> is an abomination really. Even the C standard mentions the linker
> so please...

The level of implementation specific detail you are going in to is
totally inappropriate for here. The C standard does not require a lot of
what you describe, and indeed by changing one option on Linux, AIX or
SCO I radically changed the behaviour so that one problem you talk about
goes away. On other implementations it is even further away from your
description.
--
Flash Gordon

Flash Gordon wrote:
>
> The level of implementation specific detail you are going in to is
> totally inappropriate for here. The C standard does not require a lot of
> what you describe, and indeed by changing one option on Linux, AIX or
> SCO I radically changed the behaviour so that one problem you talk about
> goes away. On other implementations it is even further away from your
> description.

I have a different view of my trade. I think a programmer

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32