Porting C software

[CBFalconer]

.... snip ...

the standard explains more than a few things, but stops well short
of a complete explanation (for example, of the exact calling
conventions, data representations, ... employed by an architecture,
which may be particularly relevant for more involved projects).

Bad idea. That immediately makes your code non-portable.

another approach (though better when combined with the standards,
so one knows more what is and is not standard) is to take some
specific implementation (say, gcc), and using this as a general
reference implementation ('how things work' and similar questions).
this is generally what I have done. how and what is done in gcc is
something I personally find particularly relevant to my own efforts.

Another bad idea, again leading to non-portable code. Isolate
anything that really has to be non-portable in a separate file, so
as to limit the rework needed during a port.

 

[CBFalconer]

.... snip ...

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

[IRONY IMPAIRED NOTE: I put that in because I thought it was funny]

Actually, it is rather sad. GCC should be compilable with
absolutely pure C90 (or C99) code (i.e. the common subset), for
maximum portability. Also, IMO, it should default to "-ansi
-pedantic -W -Wall".

 

[CBFalconer]

Jean-Pierre Mestre wrote:

.... snip about compiled under lcc-win32 and non-portable ...

That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++,
so if you want portability, port to that language.

Ugh - what an ugly idea. C and C++ are different languages, with
lots of snazzy incompatabilities. Better to fix the source
properly, after which you will have something generally useful.

 

[santosh]

cr88192 said:

...
Jean-Pierre Mestre said:


Is there a description anywhere of a "common subset" of C recognized
by all compilers?

[Summary of my reply: "C90"]

yes.

C90 is good, yes...

C99 contains a few features that look particularly problematic
(dynamic arrays and so on...).

still, should work pretty good as a reference for writing portable
code

No, it doesn't work pretty good for that. It might do one day, but it
doesn't yet. And the OP asked for a description of C that is recognised
by all compilers. C99 doesn't come anywhere near achieving that.

yes, well then one has to ask, where to find the C90 spec?...
I failed before I think, so I use the C99 spec.

<http://flash-gordon.me.uk/ansi.c.txt>

<snip>

 

[Flash Gordon]

santosh wrote, On 24/08/07 18:22:

cr88192 wrote:


<http://flash-gordon.me.uk/ansi.c.txt>

Please refer people to the CLC Wiki http://clc-wiki.net/wiki/c_standard
instead of directly to my site just in case I move it when I get things
organised. This also give credit to Dan Pop who used to provide this
download before he disappeared.

 

[jacob navia]

Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly idea.

Phil

My objective is to improve the C language retaining its simplicity.
The problem of C++ is its incredible complexity. I want to avoid that.

Therefore I have added some features I consider useful without
many others that make the language too complex.

jacob

 

[Philip Potter]

My objective is to improve the C language retaining its simplicity.
The problem of C++ is its incredible complexity. I want to avoid that.

Therefore I have added some features I consider useful without
many others that make the language too complex.

C++ is complex; but there is no problem with a programmer simply using
the subset of the language that he knows well and disregarding the rest.
At least you're still using a standard language.

There is no Pareto-efficient way to improve the C language. This is
because for every new feature you add, you reduce the portability of
programs using that feature. One of your users has just found this out
the hard way.

And what's the point in complaining about C++'s complexity when programs
written for lcc-win32's extensions need to be compiled in C++ to be
ported to any other platform?

I don't restrict my complaints about this to you and your compiler. I
don't think I'll ever understand why pretty much every compiler out
there compiles in nonstandard-bells-and-whistles mode by default. But
lesser extensions, such as // comments, mid-block declarations (in "C90"
compilers), or the #warning preprocessor directive are much easier to
edit out of an application than, say, operator overloading.

Phil

 

[Ian Collins]

My objective is to improve the C language retaining its simplicity.
The problem of C++ is its incredible complexity. I want to avoid that.

Therefore I have added some features I consider useful without
many others that make the language too complex.

This is a really dangerous thing to do, as this case shows. Someone has
been suckered into using a non-portable extension when they should have
used the language that portably supports what they are tying to do.

Such extensions don't do anyone any favors. I could understand them if
the compiler was the only option on some obscure platform, but not for
one targeted at two common hosted environments.

 

[jacob navia]

This is a really dangerous thing to do, as this case shows. Someone has
been suckered into using a non-portable extension when they should have
used the language that portably supports what they are tying to do.

Such extensions don't do anyone any favors. I could understand them if
the compiler was the only option on some obscure platform, but not for
one targeted at two common hosted environments.

I do provide implementations of the compiler under linux and windows.
If the original poster doesn't want to use them its his choice. I can't
do anything else.

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

jacob

 

[Ian Collins]

I do provide implementations of the compiler under linux and windows.
If the original poster doesn't want to use them its his choice. I can't
do anything else.

The problem is he appears to think they are C, rather than an lcc
specific extension. I've wasted way too many days porting gcc code to C
or C++, that's why I get so stroppy about compiler extensions,
especially those that are enabled by default.

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

But it doesn't, if he wanted operator overloading or a string class he
should have used C++, where they are standard and portable.

Everywhere your compiler is available, C++ compilers are available, so
what's the point?

 

[Philip Potter]

jacob navia wrote:
[Compiler extensions]

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines that
these extensions can be useful. Not that they are needed. If every
compiler extension that was used and found useful made it into the
standard we'd have a language several times larger than C++ by now.

Phil

 

[Richard Heathfield]

Ian Collins said:

This is a really dangerous thing to do, as this case shows.

The danger lies not in providing the extensions (which all implementors
do) but in promoting them as if they were part of the language.

Someone
has been suckered into using a non-portable extension when they should
have used the language that portably supports what they are tying to
do.

The user has learned one of three things: either he didn't read the
lcc-win32 documentation properly, or the implementor of lcc-win32 is an
idiot, or the implementor of lcc-win32 is malicious. A perusal of the
documentation will determine whether it's the first. If not, then
presumably Hanlon's Razor applies.

 

[jacob navia]

jacob navia wrote:
[Compiler extensions]

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines that
these extensions can be useful. Not that they are needed. If every
compiler extension that was used and found useful made it into the
standard we'd have a language several times larger than C++ by now.

Phil

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.


For instance, to cite one among many, a certain Richard Heathfield said
in a discussion in comp.std.c:

<quote>
One of the very few temptations C++ has to offer that I find hard to
resist is that of operator overloading, which is ideal for complex and
bignum types, for vector operations (in the graphical sense), and for
combinatorics.
<end quote>
Message id: <[email protected]>

He is not the only one.

Since C is not an object oriented language, and the C implementation
can build upon the C++ experience, (no overloading of the ",", "&&" or
"||" operators for instance) the end result is cleaner than the
C++ counterpart, and very easy to implement.

 

[jacob navia]

Everywhere your compiler is available, C++ compilers are available, so
what's the point?

The point is, I believe C is a good language, much simpler to use and
implement than its C++ counterpart.

The problem with C++, as I have stated elsewhere in this discussion, is
its complexity, that is impossible to avoid even if you use your own
subset. You get constructors/destructors even if you do not want them,
you can't turn that off.

You get all the complexities of templates if you want to use the
library, even if you do not use them yourself.

I am convinced that 90% of the functionality of the STL can be
reproduced in C with operator overloading, since the overloading
of the [] operators give you a standard container access.

As the development of Java proves, the complexity of C++ made simpler
languages a really needed alternative. Java (and lately C#) are just
reactions to a language whose development went too far in the direction
of complexity.

Operator overloading, and generic functions are very simple
enhancements. Most people will agree with that, and many languages
have this feature, from the venerable fortran, to many others!

What makes me curious is that if you use C++ you use those extensions,
then I do not understand your negative attitude towards the same
constructs when they are implemented in the context of C!

 

[Philip Potter]

The point is, I believe C is a good language, much simpler to use and
implement than its C++ counterpart.

The problem with C++, as I have stated elsewhere in this discussion, is
its complexity, that is impossible to avoid even if you use your own
subset. You get constructors/destructors even if you do not want them,
you can't turn that off.

I don't know what you mean by this. If you don't define a constructor or
destructor, then they do nothing. They're still there, but they don't
cause any complications.

You get all the complexities of templates if you want to use the
library, even if you do not use them yourself.

But so many people use templates, and so many people find them useful,
that there is _clearly_ a need for them in C.

(I'm using your argument in a proof by contradiction, by the way.)

I am convinced that 90% of the functionality of the STL can be
reproduced in C with operator overloading, since the overloading
of the [] operators give you a standard container access.

But the STL is one of the chief sources of complexity in C++! Why would
you want it?

As the development of Java proves, the complexity of C++ made simpler
languages a really needed alternative. Java (and lately C#) are just
reactions to a language whose development went too far in the direction
of complexity.

But Java has slowly been taking on many of the C++ features it lacked
originally. It has exceptions, generics (not-quite-templates),
inheritance, a massive standard library, etc etc. Java is hardly much
simpler - all it lacks is multiple inheritance and memory deallocation.

Operator overloading, and generic functions are very simple
enhancements. Most people will agree with that, and many languages
have this feature, from the venerable fortran, to many others!

There is no dispute here about whether or not operator overloading is
useful. But it is not in standard C, and it is not going to be in
standard C. If someone writes a program which uses operator overloading,
it will not be guaranteed to compile on all standard C compilers.

What makes me curious is that if you use C++ you use those extensions,
then I do not understand your negative attitude towards the same
constructs when they are implemented in the context of C!

We've told you before, I don't see why you'll listen this time. But here
goes:

Operator overloading in C++ is standard and portable.
Operator overloading in C is nonstandard and nonportable. Not only that,
but to change a "C plus overloading" program to a standard C program
requires a huge effort.

Phil

 

[CBFalconer]

Everywhere your compiler is available, C++ compilers are available,
so what's the point?

The point is, I believe C is a good language, much simpler to use
and implement than its C++ counterpart.

The problem with C++, as I have stated elsewhere in this discussion,
is its complexity, that is impossible to avoid even if you use your
own subset. You get constructors/destructors even if you do not want
them, you can't turn that off.

You get all the complexities of templates if you want to use the
library, even if you do not use them yourself.

I am convinced that 90% of the functionality of the STL can be
reproduced in C with operator overloading, since the overloading
of the [] operators give you a standard container access.

The problem with your approach, to my mind, is that your system
does not normally compile purely standard C. I may be in error
here. However, I believe that the system should process only
standard C and point out any variations from that. There can be
provisions to enable and disable extensions, as in GCC (which
doesn't compile standard C by default, but can be so configured).

To achieve this the developer must be familiar with standard C and
the appropriate C std. As you have demonstrated time after time in
this newsgroup, you do not have that familiarity. You are
surprised by well known C peculiarities, for example.

As the development of Java proves, the complexity of C++ made simpler
languages a really needed alternative. Java (and lately C#) are just
reactions to a language whose development went too far in the direction
of complexity.

C# is really just another Microsoft attempt to foul existing
standards and get ignorant users totally dependant on them.

 

[CBFalconer]

.... snip ...

Why is operator overloading needed?

Operator overloading is needed for creating at the user's
discretion new kind of numbers.

This is completely impossible in current C, and it is needed for
a wide variety of usages, from extra precision floating point,
bignumbers, rationals, and many other usages.

It isn't needed. It may be a convenience.

What is needed, and is currently impossible in the language, is the
definition of subrange types a la Pascal. This one addition
enables good control at compile time, but is still fouled by the
loose treatment of pointers.

 

[Ian Collins]

The point is, I believe C is a good language, much simpler to use and
implement than its C++ counterpart.

I think everyone would agree with that.

The problem with C++, as I have stated elsewhere in this discussion, is
its complexity, that is impossible to avoid even if you use your own
subset. You get constructors/destructors even if you do not want them,
you can't turn that off.

Hopefully (probably a vain hope) for the final time: YOU DO NOT. Where
do you get that daft notion from?

You get all the complexities of templates if you want to use the
library, even if you do not use them yourself.

You don't. Even if they are under then hod, as a user, you don't see them.

I am convinced that 90% of the functionality of the STL can be
reproduced in C with operator overloading, since the overloading
of the [] operators give you a standard container access.

If it could be reproduced in C with operator overloading, it could be
done in C++ with operator overloading, which it can't.

As the development of Java proves, the complexity of C++ made simpler
languages a really needed alternative. Java (and lately C#) are just
reactions to a language whose development went too far in the direction
of complexity.

Tell that the the implementors of generics.

Operator overloading, and generic functions are very simple
enhancements. Most people will agree with that, and many languages
have this feature, from the venerable fortran, to many others!

What makes me curious is that if you use C++ you use those extensions,
then I do not understand your negative attitude towards the same
constructs when they are implemented in the context of C!

Because they don't belong in C. There are many useful features in C++
that aren't in C and never will be. if I want to use them I use C++.

 

[Spiros Bousbouras]

jacob navia wrote:
[Compiler extensions]

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines that
these extensions can be useful. Not that they are needed. If every
compiler extension that was used and found useful made it into the
standard we'd have a language several times larger than C++ by now.

Phil

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.

If you want extra numeric types what's wrong with having
functions add() , subtr() etc. to handle those types ? Why
overload the already existing operators ?

 

[Keith Thompson]

... snip about compiled under lcc-win32 and non-portable ...

Ugh - what an ugly idea. C and C++ are different languages, with
lots of snazzy incompatabilities. Better to fix the source
properly, after which you will have something generally useful.

Maybe. But without knowing much about the appication, it's possible
that it really depends on some of those extensions. Perhaps it should
have been written in C++ in the first place.

Of course it's also entirely possible that you're right and that it
would be better to write it in portable C.