Porting C software

[jacob navia]

John Smith said:



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.


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]

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

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

--

 

[Tor Rustad]

Joe Wright said:



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.


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!

 

[Keith Thompson]

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.

 

[Mark McIntyre]

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:

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.

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.

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.

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.

 

[Ian Collins]

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

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

I think the definition of name mangling has been lost in the noise.

Consistently changing all function names (such as prepending an
underscore) does not constitute name mangling.

Making (implementation defined) changes to function names based on their
parameter types, as required for any form of function overloading, does.


C does not have function overloading, so it does not require any form of
name mangling. Once an extension is added to a compiler that changes
this, the compiler is no longer a C compiler.

 

[jacob navia]

I think the definition of name mangling has been lost in the noise.

Consistently changing all function names (such as prepending an
underscore) does not constitute name mangling.

Making (implementation defined) changes to function names based on their
parameter types, as required for any form of function overloading, does.

The stdcall name mangling does this:

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

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

C does not have function overloading, so it does not require any form of
name mangling.

What about the above?

Once an extension is added to a compiler that changes
this, the compiler is no longer a C compiler.

There is no change to the name of the function:

the compiler figures out a function name for the operator and
generates a function call!

 

[Ian Collins]

The stdcall name mangling does this:

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

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

It is, but it's a windows thing, not a C one.

What about the above?

It is done by the implementation, not required by the language.

There is no change to the name of the function:

the compiler figures out a function name for the operator and
generates a function call!

So it generates a name based on the argument type? Then that's a
mangled name.

 

[Mark McIntyre]

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]

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

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]

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 ?