Porting C software

[Jean-Pierre Mestre]

Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

Thanks to all!
J-P.

[jacob navia]

Richard wrote:

Ian Collins <ia******@hotmail.comwrites:

>jacob navia wrote:

>>Ian Collins wrote:
jacob navia wrote:
This makes possible:
>
int fn(void)
{
OtherNumber f = 56;
But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Wow.

So

const OtherNumber array[] {1,2,3};

isn't an initialisation?

In fairness, he didn't say it isn't. He just says, and I can understand
why, that he doesn't bother to distinguish since it has little if any
effect in the understanding of how the program behaves. In this case it
doesn't kill the system to consider this as a one off assignment. I can't see
how this way of thinking damages anything.

I can't really UNDERSTAND the difference between

1) assignment to a previously undefined variable
2) initialization of a variable

For me this is bogus and OVER-BOGUS.

There is no difference at all.

[jacob navia]

Fr************@googlemail.com wrote:

[snip]

I've only been reading this group for a few
months and I've managed to pick it up already :)

[snip]

It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

Great Francine!

In a few months you have picked up everything you need to know!

Very clever.

You have understood that

1) Insulting people is the way to go in this newsgroup.

2) Avoiding any substantial argumentation or technical content
in your posts and just leaving insults and polemic.

You are ALL SET!!!

I wish you from my mentally unstable state ALL Well!

Yours sincerely

jacob

[Jean-Pierre Mestre]

Good evening,

So my problem seems to have generated very many responses!

I can say that after many terribles days I have removed all dependencies
on overloading and safe strings!

I hope no one more will have to do this!

Mr Navia, I ask you to remove the extra features from your compiler so
that people will be able to write C programs that they will be able to
port to other systems.

Best to all,
J-P.
On 24 Aug 2007 at 14:07, Ben Bacarisse wrote:

Jean-Pierre Mestre <a.*@c.comwrites:

>Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized by
lcc.

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

As a practical matter, you don't need to convert everything to this
common subset right now. For example, if the language accepted by
lcc-win32 (I'll call it LC) allows // comments and mixed statements
and declarations, then you can leave these for the time being since
you are certain to find a compiler on Linux where these are
unproblematic. You may choose to change these later for maximum
portability, but they are not much of a problem right now.

The hardest problem may come from the fact that LC has a garbage
collector so, depending on how your program is written, it may not free
any of the storage it allocates. The quick solution to this is to use
a garbage collector on the new platform.

<OT>http://www.hpl.hp.com/personal/Hans_Boehm/gc/ is considered a good
one.</OT>

Garbage collected languages encourage a different style (at least as
far as storage management is concerned) from non-GC languages so you
will need to see how far that style has penetrated into the code.

[Default User]

Jean-Pierre Mestre wrote:

Good evening,

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>You should be able to use your new type as if it were a built in one,
otherwise the job is incomplete.

Please correct me if I am wrong, but how do you do this in C++?

static OtherNumberType OtherTypeArray[] = {1,2,3,4,5};

As written, but the static would be superfluous.

at the GLOBAL level?

or

static OtherNumberType Myvar =
4555566665544444455544545454.887787778777777789888 778;

add a constructor from const char* and write the number as a string literal.

As far as I remember that is NOT possible at the global level.

It is.

I suggest we take this to email!

--
Ian Collins.

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>
The way to overcome this is to standardize the name mangling, to
keep binary compatibility. Anyway, binary compatibility is NOT
guaranteed even today.

C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.

>
If you use Microsoft visual C, it is impossible to link with gcc
anyway. And the other way around, even under the same OS.

Of course. The object code, linking, etc. is system specific.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[Mark McIntyre]

On Fri, 31 Aug 2007 21:27:00 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>
I think that since everybody (heathfield included) agrees that this is
missing from the language

Richard merely listed it as an attraction of C++. Similarly I find
ladies' chests attractive, that doesn't mean I want one...

>why don't we try to specify how that could be
included?

That would be topical over in comp.std.c

>The founder of this group wrote on Fri Oct 22 01:28:04 1982:

1982 was twenty seven years ago. Big Hair was fashionable back then,
and the Soviet Union still existed.

Suggestions for C modifications or extensions

*shrug*. Just 'cos someone suggested it, doesn't mean it was agreed
on then, or remains agreed on today.

Also back in those days there were a few hundred newsgroups, highly
limited bandwidth and probably only a few tens of thousands of users.
Nowadays there are gazillios of all three and plenty of room to
discuss all sorts of stuff in its own little space.

>Is this a discussion group about a DEAD (no longer growing)
language?

No.

But you know all this, you're simply trolling yet again.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Fri, 31 Aug 2007 22:26:12 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>
In a few months you have picked up everything you need to know!

Very clever.

Its interesting isn't it, that most threads involving Jacob tend
quickly to turn into JN being provocative and everyone else being
initially polite, then exasperated, then plain rude. /Then/ JN
complains and/or claims that someone else is at fault.

I'm looking for the common factor...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[John Smith]

Fr************@googlemail.com wrote:

It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

Francine, Jacob has some unconventional ideas and clearly shows
signs of frustration in getting them across, but he doesn't
deserve to be the Rodney Dangerfield of c.l.c. Your comments will
be taken more seriously after you give the group a look at the C
implementation you wrote.

JS

[CBFalconer]

jacob navia wrote:

Ian Collins wrote:

.... snip ...

>>
You should be able to use your new type as if it were a built in
one, otherwise the job is incomplete.

Please correct me if I am wrong, but how do you do this in C++?

Please ask OT C++ questions in c.l.c++, and NOT here.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[Francine.Neary]

On Aug 31, 10:56 pm, John Smith <[e-mail]:

[e-mail] wrote:

It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

Francine, Jacob has some unconventional ideas and clearly shows
signs of frustration in getting them across, but he doesn't
deserve to be the Rodney Dangerfield of c.l.c. Your comments will
be taken more seriously after you give the group a look at the C
implementation you wrote.

Firstly, as far as we know, Jacob hasn't written a C implementation,
but an implementation of a hybrid language called lccwin32 which has
elements of C and C++ in it. Secondly, I don't follow your argument
that writing an implementation gives someone the right to flood a
newsgroup with off-topic posts.

As for me, if I did write a C implementation then
1) it would be an implementation of C, not some made-up language
2) I wouldn't release it under an onerous proprietary license
3) I wouldn't spam technical newsgroups with incessant advertisements
for it.

JS

[jacob navia]

John Smith wrote:

Fr************@googlemail.com wrote:

>It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

Francine, Jacob has some unconventional ideas and clearly shows signs of
frustration in getting them across, but he doesn't deserve to be the
Rodney Dangerfield of c.l.c. Your comments will be taken more seriously
after you give the group a look at the C implementation you wrote.

JS

Forget it John. Its just not worth the effort. Polemic and polemic
for no reason.

That is how they kill the discussion. Nobody speaks about the issues any
more.

On the positive side, I learned from this discussion that there is a
hole in my implementation:

Arrays.

If you overload the assignment or the cast operator, you should be able
to do:

MyNumericType Table[] = {1,2,3,4};

and I should generate a call to the overloaded assignment or cast
operator (in that sequence) for each array position, passing it an
integer.

This looks tricky but is doable.

[Ben Pfaff]

CBFalconer <cb********@yahoo.comwrites:

C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.

C implementations are allowed to do name mangling. It's just
that most don't.
--
"It wouldn't be a new C standard if it didn't give a
new meaning to the word `static'."
--Peter Seebach on C99

[Joe Wright]

Fr************@googlemail.com wrote:

On Aug 31, 10:56 pm, John Smith <[e-mail]:

>[e-mail] wrote:

>>It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

Francine, Jacob has some unconventional ideas and clearly shows
signs of frustration in getting them across, but he doesn't
deserve to be the Rodney Dangerfield of c.l.c. Your comments will
be taken more seriously after you give the group a look at the C
implementation you wrote.

Firstly, as far as we know, Jacob hasn't written a C implementation,
but an implementation of a hybrid language called lccwin32 which has
elements of C and C++ in it. Secondly, I don't follow your argument
that writing an implementation gives someone the right to flood a
newsgroup with off-topic posts.

As for me, if I did write a C implementation then
1) it would be an implementation of C, not some made-up language
2) I wouldn't release it under an onerous proprietary license
3) I wouldn't spam technical newsgroups with incessant advertisements
for it.

You go girl!
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[jacob navia]

Ben Pfaff wrote:

CBFalconer <cb********@yahoo.comwrites:

>C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.

C implementations are allowed to do name mangling. It's just
that most don't.

All implementations under windows do it.
Under the a.out format, gcc prefixed with an underscore all names, what
many compilers still do.

I would say that MOST of them do, except gcc now.

[Mark McIntyre]

On Sat, 01 Sep 2007 02:07:07 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Ben Pfaff wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.

C implementations are allowed to do name mangling. It's just
that most don't.

All implementations under windows do it.

They don't. However discussion of what they do is offtopic here.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Flash Gordon]

jacob navia wrote, On 31/08/07 19:11:

Ian Collins wrote:

>jacob navia wrote:

>>Keith Thompson wrote:
It seems to me that most of your extensions are more or less
compatible with C++. In other words, the language you want is
somewhere *between* C and C++.

Wouldn't it have been easier to take an existing C++ compiler and
selectively disable the features you don't like? (And then it *might*
be reasonable to discuss it in comp.lang.c++.)

As I have said many times the crux of the matter is the object oriented
aspects of C++.

For instance the operator [] can only be overloaded within a class
definition, hence it has the implicit "this" argument. This would break
C, and transform it into C++.

And the support required for your extensions doesn't?

As soon as you add references (which probably is a good extension to C)
and overloading, you start to break ABI compatibility with other C
compilers on your platform.

This is a problem.

The way to overcome this is to standardize the name mangling, to keep
binary compatibility.

Try that and at least one OS with a large user base will have to break
binary compatibility with most existing applications for that OS.

Anyway, binary compatibility is NOT guaranteed even today.

It generally is within an OS.

If you use Microsoft visual C, it is impossible to link with gcc anyway.
And the other way around, even under the same OS.

The Cygwin web site has instructions for how to use MS Visual Studio to
link to the Cygwin DLL, and the Cygwin DLL is build with gcc, so this is
clearly rubbish. It also has instructions on how to use the gcc that
comes with Cygwin to link to any DLL that is not stripped. It is all in
their FAQ.

Personally I've linked to DLLs written in Visual Studio from Delphi
which again shows a degree of "standardisation" within Windows.
--
Flash Gordon

[Richard Heathfield]

John Smith said:

<snip>

Francine, Jacob has some unconventional ideas and clearly shows
signs of frustration in getting them across, but he doesn't
deserve to be the Rodney Dangerfield of c.l.c.

He's brought that on himself. He's been told many times that suggestions
about changes to the language belong in comp.std.c; anyone who is
incapable of absorbing and acting upon information as simple as that is
probably also incapable of coming up with a sensible proposal for
language change.

Your comments will
be taken more seriously after you give the group a look at the C
implementation you wrote.

As far as this newsgroup is aware, all Mr Navia has done is to take an
existing implementation and tweak it a bit. On one occasion (IIRC), he
claimed that he has now re-written the entire thing, but it is far from
clear whether this is actually the case. Since the source code is not
available for inspection, it is difficult to check the claim. Since Mr
Navia often posts code here that doesn't even compile, let's just say
that I'm sceptical.

For the record, I take Francine's comments far more seriously than I
take Mr Navia's comments.

Also for the record, I used to accord Mr Navia a lot /more/ respect, for
much the same reasons that you do. Over the years, however, I feel that
I have got to know him much better.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Pfaff]

jacob navia <ja***@jacob.remcomp.frwrites:

Ben Pfaff wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.

C implementations are allowed to do name mangling. It's just
that most don't.

All implementations under windows do it.
Under the a.out format, gcc prefixed with an underscore all names, what
many compilers still do.

The Windows custom of prefixing a name with an underscore is not
customarily called name mangling. It is just a prefix.
--
"...what folly I commit, I dedicate to you."
--William Shakespeare, _Troilus and Cressida_

[Ian Collins]

Ben Pfaff wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>Ben Pfaff wrote:

>>CBFalconer <cb********@yahoo.comwrites:

C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.
C implementations are allowed to do name mangling. It's just
that most don't.

All implementations under windows do it.
Under the a.out format, gcc prefixed with an underscore all names, what
many compilers still do.

The Windows custom of prefixing a name with an underscore is not
customarily called name mangling. It is just a prefix.

And is very widely used on other platforms, so it probably predates windows.

--
Ian Collins.

[jacob navia]

Ben Pfaff wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>Ben Pfaff wrote:

>>CBFalconer <cb********@yahoo.comwrites:

C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.
C implementations are allowed to do name mangling. It's just
that most don't.

All implementations under windows do it.
Under the a.out format, gcc prefixed with an underscore all names, what
many compilers still do.

The Windows custom of prefixing a name with an underscore is not
customarily called name mangling. It is just a prefix.

I am speaking about stdcall name mangling.

Without that you can't link with the system libraries

[jacob navia]

Ian Collins wrote:

Ben Pfaff wrote:

>jacob navia <ja***@jacob.remcomp.frwrites:

>>Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:

C does not do name mangling. It's only purpose is to enable reuse
of function names by appending peculiarities in other languages,
which are off-topic here.
C implementations are allowed to do name mangling. It's just
that most don't.
All implementations under windows do it.
Under the a.out format, gcc prefixed with an underscore all names, what
many compilers still do.

The Windows custom of prefixing a name with an underscore is not
customarily called name mangling. It is just a prefix.

And is very widely used on other platforms, so it probably predates windows.

I am speaking about stdcall name mangling. Without it you can't link
with the system libraries, so its mandatory.

[jacob navia]

Flash Gordon wrote:

jacob navia wrote, On 31/08/07 19:11:

>Ian Collins wrote:

>>jacob navia wrote:
Keith Thompson wrote:
It seems to me that most of your extensions are more or less
compatible with C++. In other words, the language you want is
somewhere *between* C and C++.
>
Wouldn't it have been easier to take an existing C++ compiler and
selectively disable the features you don't like? (And then it *might*
be reasonable to discuss it in comp.lang.c++.)
>
As I have said many times the crux of the matter is the object oriented
aspects of C++.

For instance the operator [] can only be overloaded within a class
definition, hence it has the implicit "this" argument. This would break
C, and transform it into C++.

And the support required for your extensions doesn't?

As soon as you add references (which probably is a good extension to C)
and overloading, you start to break ABI compatibility with other C
compilers on your platform.

This is a problem.

The way to overcome this is to standardize the name mangling, to keep
binary compatibility.

Try that and at least one OS with a large user base will have to break
binary compatibility with most existing applications for that OS.

>Anyway, binary compatibility is NOT guaranteed even today.

It generally is within an OS.

>If you use Microsoft visual C, it is impossible to link with gcc anyway.
And the other way around, even under the same OS.

The Cygwin web site has instructions for how to use MS Visual Studio to
link to the Cygwin DLL, and the Cygwin DLL is build with gcc, so this is
clearly rubbish.

For dynamic linking you do not need any binary compatibility of
course. It is similar to doing

system("bla bla");

You are not linking with it, just loading an executable into your
address space.

I haven't seen those instructions but it would be intersting to know
what happens if you malloc something with cygwin and free() it with
microsoft. Or open a file with Microsoft and fclose () it with cygwin.

Go and try, you will see the result.

That library is probably not doing anything like this.

It also has instructions on how to use the gcc that
comes with Cygwin to link to any DLL that is not stripped. It is all in
their FAQ.

Dynamic linking is possible this ways. Those instructions tell you
HOW TO AVOID THE NAME MANGLING PROBLEM and would work with any
compiler.

Personally I've linked to DLLs written in Visual Studio from Delphi
which again shows a degree of "standardisation" within Windows.

No. It shows that windows can do this even with different
name mangling schemas. You can do the same with lcc-win32.

[John Smith]

Fr************@googlemail.com wrote:

On Aug 31, 10:56 pm, John Smith <[e-mail]:

>>[e-mail] wrote:

>>>It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

Francine, Jacob has some unconventional ideas and clearly shows
signs of frustration in getting them across, but he doesn't
deserve to be the Rodney Dangerfield of c.l.c. Your comments will
be taken more seriously after you give the group a look at the C
implementation you wrote.

Firstly, as far as we know, Jacob hasn't written a C implementation,
but an implementation of a hybrid language called lccwin32 which has
elements of C and C++ in it. Secondly, I don't follow your argument
that writing an implementation gives someone the right to flood a
newsgroup with off-topic posts.

As for me, if I did write a C implementation then
1) it would be an implementation of C, not some made-up language
2) I wouldn't release it under an onerous proprietary license
3) I wouldn't spam technical newsgroups with incessant advertisements
for it.

>>JS

Until we see your work, we can safely assume you're not capable
of writing an implementation of any language.

1. Whatever else it is, it's a functional C compiler. It compiles
my standard, portable C code perfectly well. (Although I use it
only for testing.)
2. As far as I can recall, I downloaded and installed it without
having to agree to the terms of any license. It is, for all
intents and purposes, free software.
3. Accusing him of spamming the group with ads is hyperbole. He
occasionally recommends it to beginners looking for a compiler.
4. Go away.

JS

JS

[Richard Heathfield]

John Smith said:

<snip>

3. Accusing him of spamming the group with ads is hyperbole.

It's unsolicited electronic advertising. You can think of some other
word than spam if you like, but it's still an abuse of the group.

He
occasionally recommends it to beginners looking for a compiler.

Beginners need working compilers written by people who know the
language. Mr Navia frequently demonstrates his ignorance of C in this
group. If lcc-win32 works, it is hard to believe that he wrote it. If
he wrote it, it is hard to believe that it works.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

John Smith said:

<snip>

>3. Accusing him of spamming the group with ads is hyperbole.

It's unsolicited electronic advertising. You can think of some other
word than spam if you like, but it's still an abuse of the group.

>He
occasionally recommends it to beginners looking for a compiler.

Beginners need working compilers written by people who know the
language. Mr Navia frequently demonstrates his ignorance of C in this
group.

I haven't published a book where I assume
sizeof(int) == sizeof(int *) like you.
If lcc-win32 works, it is hard to believe that he wrote it. If

he wrote it, it is hard to believe that it works.

I have no doubt that assuming sizeof(int) == sizeof(int *) comes
from heathfield.

[Richard]

jacob navia <ja***@jacob.remcomp.frwrites:

Richard Heathfield wrote:

>John Smith said:

<snip>

>>3. Accusing him of spamming the group with ads is hyperbole.

It's unsolicited electronic advertising. You can think of some other
word than spam if you like, but it's still an abuse of the group.

>>He
occasionally recommends it to beginners looking for a compiler.

Beginners need working compilers written by people who know the
language. Mr Navia frequently demonstrates his ignorance of C in
this group.

I haven't published a book where I assume
sizeof(int) == sizeof(int *) like you.

Everyone makes mistakes. It is poor form, and Heathfield'esque , to pick
up on them as if they were meant to be the correct form. It's not a bad
book but there are many better.

If lcc-win32 works, it is hard to believe that he wrote it. If

>he wrote it, it is hard to believe that it works.

I have no doubt that assuming sizeof(int) == sizeof(int *) comes
from heathfield.

--

[Tor Rustad]

Richard Heathfield wrote:

Joe Wright said:

<snip>

>I do miss Dan but he wasn't right all the time.

Very true. I found myself disagreeing with him quite a few times

I can remember those endless Heathfield vs Pop threads!

Dan Pop was be among the top 10 posters all the time.. Lawrence Kirby
was not, so catching Dan in a mistake, would naturally be easier.

>Heathfield was pretty good when he was younger. :-) g,d&r

He even flamed Dennis M. Ritchie...! Yeah, those good old days with Pop,
Kaz and the young Pfaff flaming the clueless, clc was an excellent place!
--
Tor <torust [at] online [dot] no>

[Keith Thompson]

John Smith <JS****@mail.netwrites:

Fr************@googlemail.com wrote:

>On Aug 31, 10:56 pm, John Smith <[e-mail]:

>>>[e-mail] wrote:
It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

Francine, Jacob has some unconventional ideas and clearly shows
signs of frustration in getting them across, but he doesn't
deserve to be the Rodney Dangerfield of c.l.c. Your comments will
be taken more seriously after you give the group a look at the C
implementation you wrote.

Firstly, as far as we know, Jacob hasn't written a C implementation,
but an implementation of a hybrid language called lccwin32 which has
elements of C and C++ in it. Secondly, I don't follow your argument
that writing an implementation gives someone the right to flood a
newsgroup with off-topic posts.
As for me, if I did write a C implementation then
1) it would be an implementation of C, not some made-up language
2) I wouldn't release it under an onerous proprietary license
3) I wouldn't spam technical newsgroups with incessant advertisements
for it.

Until we see your work, we can safely assume you're not capable of
writing an implementation of any language.

No we can't assume any such thing. But it doesn't matter; writing a C
compiler is neither necessary nor sufficient for being taken seriously
in this newsgroup.

1. Whatever else it is, it's a functional C compiler. It compiles my
standard, portable C code perfectly well. (Although I use it only for
testing.)

lcc-win32 is, as far as I can tell, a conforming C90 (C95?) compiler
and a mostly conforming C99 compiler. (There are a few C99 features
that jacob hasn't implemented yet, but he rarely admits that when
talking about its C99 support.)

It also implements a number of non-standard extensions, some of which
are probably allowed by the standard (i.e., they don't alter the
behavior of any strictly conforming program), and some of which may
not be (e.g., if it treats 'qfloat' as a keyword that can break valid
code that uses it as an identifier). But it has an option that
disables most of those extensions. With that option, I'm not aware of
any conformance failures (other than the missing C99 features).

It's not surprising that some people aren't aware of this, since jacob
spends much more time here pushing his extensions than worrying about
conformance to the standard.

I can't comment on the quality of the compiler, since I don't use it.

But the real point is that jacob, like everyone else here, is judged
by what he posts here, not by what he's done elsewhere.

When *anyone* makes a mistake here, it's corrected. When *anyone*
disregards the topic of the newsgroup, it's pointed out.
Unfortunately, jacob happens to do this more than most other people
here.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Mark McIntyre]

On Sat, 01 Sep 2007 06:50:44 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Ben Pfaff wrote:

>The Windows custom of prefixing a name with an underscore is not
customarily called name mangling. It is just a prefix.

I am speaking about stdcall name mangling.

Without that you can't link with the system libraries

Its still not name mangling.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Flash Gordon]

jacob navia wrote, On 01/09/07 05:56:

Flash Gordon wrote:

>jacob navia wrote, On 31/08/07 19:11:

>>Ian Collins wrote:
jacob navia wrote:
Keith Thompson wrote:
>It seems to me that most of your extensions are more or less
>compatible with C++. In other words, the language you want is
>somewhere *between* C and C++.
>>
>Wouldn't it have been easier to take an existing C++ compiler and
>selectively disable the features you don't like? (And then it
>*might*
>be reasonable to discuss it in comp.lang.c++.)
>>
As I have said many times the crux of the matter is the object
oriented
aspects of C++.
>
For instance the operator [] can only be overloaded within a class
definition, hence it has the implicit "this" argument. This would
break
C, and transform it into C++.
>
And the support required for your extensions doesn't?

As soon as you add references (which probably is a good extension to C)
and overloading, you start to break ABI compatibility with other C
compilers on your platform.

This is a problem.

The way to overcome this is to standardize the name mangling, to keep
binary compatibility.

Try that and at least one OS with a large user base will have to break
binary compatibility with most existing applications for that OS.

I note that you ignored this point. Unless you address it I will assume
you agree with it and accept that it is not practical to standardise
name mangling.

>>Anyway, binary compatibility is NOT guaranteed even today.

It generally is within an OS.

>>If you use Microsoft visual C, it is impossible to link with gcc anyway.
And the other way around, even under the same OS.

The Cygwin web site has instructions for how to use MS Visual Studio
to link to the Cygwin DLL, and the Cygwin DLL is build with gcc, so
this is clearly rubbish.

For dynamic linking you do not need any binary compatibility of

^^^^^^^

course. It is similar to doing

Try passing a 64 bit int when a 32 bit int is expected and see what happens.

system("bla bla");

You are not linking with it, just loading an executable into your
address space.

Note the second word in the term "dynamic linking".

I haven't seen those instructions but it would be intersting to know
what happens if you malloc something with cygwin and free() it with
microsoft. Or open a file with Microsoft and fclose () it with cygwin.

Go and try, you will see the result.

That library is probably not doing anything like this.

Actually, if you compile with the appropriate options (telling it to act
like mingw) then it is using the Microsoft runtime libraries distributed
with Windows, so it will work perfectly. Alternatively use MinGW and it
will work perfectly.

It also has instructions on how to use the gcc that
comes with Cygwin to link to any DLL that is not stripped. It is all
in their FAQ.

Dynamic linking is possible this ways.

Dynamic linking is a form of linking so it solves the problem.

Those instructions tell you
HOW TO AVOID THE NAME MANGLING PROBLEM and would work with any
compiler.

Ah, so you *can* link code from any Windows compiler.

>Personally I've linked to DLLs written in Visual Studio from Delphi
which again shows a degree of "standardisation" within Windows.

No. It shows that windows can do this even with different
name mangling schemas.

I did not have to do anything to handle different name-mangling schemas.

You can do the same with lcc-win32.

Since the MinGW port of gcc uses the same runtime library as MSVC it by
definition natively handles one "standard" convention used by MSVC.
Otherwise it would not find fopen.
--
Flash Gordon

[Mark McIntyre]

On Sun, 02 Sep 2007 10:14:44 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>The stdcall name mangling does this:

int fn(int,long);
to
_fn@8

(or some implementation-defined number to say how large the args are
in bytes).

>SO it is name mangling according to your definition: based on their
parameter types.

Name-mangling allows the linker to differentiate between functions
with the same name but different parameters. The stdcall mechanism
does not. This is name decoration, not mangling.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Bos]

Richard <rg****@gmail.comwrote:

Keith Thompson <ks***@mib.orgwrites:

jacob navia <ja***@jacob.remcomp.frwrites:

heathfield,

*Smack* _You_ write your name with lower case initials. _He_ writes his
with upper case. Please have the mere decency to spell other people's
names the way they want them spelled, or shall we call you Jackie?

You wrote in comp.std.c, under the thread

"implcit inr" the following:

<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>

I agree with you.

Was that an attempt to refute Richard's statement that this discussion
is off-topic here?

I believe he was discussing the hypothetical possibility of adding
operator overloading to a future version of the C standard. That's
perfectly topical in comp.std.c.

Not according to RH it isn't. Since it's not "standard C".

Excuse me: it was topical in comp._std_.c, where it was posted. It is
indeed not topical here.

That's why we have different groups, you know. To make them useful to
different kinds of posters. Or did you want to post everything in
misc.misc?

,----
| (defun cg-gnus-summary-ignore-thread ()
| (interactive)
| (let* ((hdr (gnus-summary-article-header))
| (subj (aref hdr 1)))
| (gnus-summary-score-entry "Subject" subj 'S' -1000
| (current-time-string))
| (gnus-summary-limit-to-unread)
| (gnus-summary-scroll-up 0)))
|
| ;;F7 ignores a thread
| (define-key gnus-summary-mode-map (kbd "<f7>") 'cg-gnus-summary-ignore-thread)
`----

And Lisp is off-topic here, and you know it, dammit!

Richard





(Yes, that last remark (and that one only) should be read with a ;-) )

[Spiros Bousbouras]

On Sep 1, 12:29 am, jacob navia <[e-mail]:

If you overload the assignment or the cast operator, you should be able
to do:

MyNumericType Table[] = {1,2,3,4};

and I should generate a call to the overloaded assignment or cast
operator (in that sequence) for each array position, passing it an
integer.

This looks tricky but is doable.

Should we conclude then that, contrary to your earlier
assertions, implementing your extensions is not easy ?