On 27/08/18 13:18, Bart wrote:
> On 27/08/2018 06:53, David Brown wrote:
>> On 26/08/18 19:19, Bart wrote:
>>> On 26/08/2018 15:37, David Brown wrote:
>>>> On 25/08/18 13:35, Bart wrote:
>>>
>>>>> I'm sorry but isn't one of the primary jobs of a linker to detect
>>>>> such clashes? It's not something you have to prod it into doing!)
>>>>>
>>>>
>>>> Well, you /have/ been told all the details about this problem
>>>> before, and given the gcc switches used to detect and avoid it.
>>>
>>> Was I? Am I supposed to remember each one of dozens of options for
>>> every blatant error that gcc ignores unless you give it a good kick
>>> up the backside?
>>
>> No, you are supposed to remember a bit about how the C language,
>> compilers, and linkers work
>
> Which ones? I routinely use half a dozen (7 actually) different C
> compilers.
My explanation covers the way most assemblers, C compilers and linkers
are built up. It does not go into the fine details. And of course some
tools will be implemented differently, or be more limited. A
general-purpose linker will support "common" data, but one written
specifically for C might not.
>
> If the C compiler is called THISCC then I just want to be able to do this:
>
> THISCC prog.c
>
> and it is expected to produce an object file (some require -c or
> equivalent).
Whether a C compiler produces an object file or an assembly file is a
matter of implementation detail. What sections are used in the object
file, what format it has, and all the other bits and pieces are
implementation dependent (possibly specified by the OS or target ABI,
but certainly not by C standards).
What you really want is a magical tool that will find all your errors,
take your incorrect input code and generate the output code you wanted,
read your mind regarding what mixture of C standards and extensions you
like, and give you a result that suits your precise needs - all without
telling the compiler anything. Ideally it should figure out for itself
which input file to use, and the result should be generated before you
have even finished writing the source code. The compiler should, of
course, be so compact that it can be put in the signature of a Usenet post.
Until you have this tool, you have to live with the ones that exist in
the real world. I have been doing my best to explain how they work, how
you should use them, and (sometimes) why they are the apparently odd way
they sometimes are.
As I see it, you have two choices here. You can continue to complain
that others don't re-arrange the entire programming world, including all
C code ever written, to suit your desires and your fantasies. Or you
can write a little "my_gcc.bat" file with the common compiler options
you need, and use that as your "THISCC". When you have figured out
which path would be most productive, let us all know.
>
> It is also expected to tell me what's wrong with the program - actually
> wrong, not wrong according to some interpretation agree beforehand with
> the compiler via sets of options. All those one-line program posted 10
> hours ago I would expect to fail.
>
> As to linkers: I just want them to do their job, and report three kinds
> of error: can't find a module, can't find a symbol, or multiple
> definitions of the same symbol. It's not hard.
>
> In short, a C compiler and linker should just be expected to do their
> jobs. The only options you need to remember are the basic:
>
> * How to enable optimising
> * How to select between targets if there is a choice with the same build
> of the compiler
> * How to do compile-only or preprocess only when it normally attempts
> something else.
>
And many, many other things - because there are many, many people that
use compilers, for many types of code and many purposes. The world does
not revolve around /you/.
> Which will all vary across compilers.
Unfortunate, perhaps, but true.
>
> when you have had a discussion about them
>> and when you claim to be capable of writing a C compiler and a linker.
>
> Mine might have poor qualities in some respects, but they manage to get
> the basics right. They outright reject (not just pass, with
> admonishments) those one-liners, with having to feed in any extra
> options, and the linker does exactly what is expected of it. Namely,
> detect when the same symbol is exported from different modules, WITHOUT
> having to be given special instructions.
And your tools are useless to most C programmers. Whatever qualities
they may or may or may not have, the won't do the job for other people.
>
> As usual, this is not going to cut any ice with anyone here. The way all
> those cumbersome tools behave MUST be better!
>
Of course - tools that work are /better/. Your tools may be good for
/you/, and the programs /you/ write for the systems /you/ use. They are
not suitable for most other purposes. Tools that /are/ suitable for the
wide range of uses C gets are, necessarily, large and complicated.
>
>>> The last 3 variables have no storage of there own, but are aliases
>>> for different regions in another called 'common' (which is not a
>>> special name; it could be any variable).
>>
>> That is not a /use/ of "common" storage - that is an illustration of
>> the problems people get with it.
>
> It's an illustration of how to get the effects of COMMON, without
> foregoing the ability to detect multiple definitions of a symbol.
>
No, it isn't - because it is not even close to C. I am sure that some
sort of "@" extension could be added to a C compiler (I have seen such
extensions in embedded compilers, though the address is given as fixed
absolute addresses). There are other ways to simulate accessing data in
different ways but the same address - from legal methods (unions) to
ones that will work on almost any compiler (pointer casts with
"volatile") to ones that might work sometimes (pointer casts without
volatile) and very implementation-specific methods (weak aliases,
assembly, linker scripts).
The point, however, is that common symbols are a /bad/ idea. They are a
product of a bygone age, and are only supported now because they have
been used in old code that still needs to be supported by modern
compilers. We don't want to simulate them or get the same effect in
other ways!