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.

 

[Ben Pfaff]

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?

No, these are lccwin32-specific features. You will have to
modify your software not to use them if you want to be able to
use it with any other C implementation.

 

[Richard Heathfield]

Jean-Pierre Mestre said:

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.

C doesn't have either feature. These are extensions to the language,
provided by the implementor. You have just discovered why one should
think very seriously before taking advantage of extensions - they make
porting the code much more difficult.

Is there a compiler for Unix with
these advanced features, or what's the best way to port them across?

The best way to regain the portability you desire is to rewrite the
program in C.

 

[Ben Bacarisse]

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

<off topic>lcc-win32 is not FLOSS as far as I know. FLOSS (Free,
Libre, Open Source Software) is something of a catch-all but I don't
think the term extends to software that is simply free for

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?

The cleanest solution would be replace the String objects with one of
the fine, freely-available string libraries (sorry I have no link for
you but at least two are written by regulars here) and to hand un-pick
the operator overloading.

If there is a lot if it, and the semantics of lcc-win32's overloading
is close match, there *may* be some mileage in targeting g++ (the C++
compile in the GNU family) since that has string objects in a standard
library and operator overloading in the language. Of course, the
details end up being off topic for this group -- as soon as your code
goes near a C++ compiler is becomes C++ and you need the expertise of
C++ people to guide you (
[Obviously, avoid any gcc extensions as well -- the code is being
ported once, so it may have to be ported again.]

 

[santosh]

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.

AFAIK, lcc-win32 is not FLOSS. It's Freeware.

I try gcc but now it doesn't work

That's because the code uses lcc-win32 specific extensions.

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?

I may be wrong, but jacob mentioned sporadically that there exists, or that
he is working on, a port of his compiler for Linux. Maybe you should
contact him?

If you've used these extensions heavily, it may be very time consuming to
modify your source to compile under an ISO complaint compiler.

Also consider taking further queries about lcc-win32 code to
comp.compilers.lcc

 

[Keith Thompson]

AFAIK, lcc-win32 is not FLOSS. It's Freeware.

Different people will have different understandings of what the term
"Freeware" means. Rather than trying to resolve it, I'll just say
that it's possible to download and use lcc-win32 without paying any
money for it. Obtaining sources is a separate question.

[...]

Also consider taking further queries about lcc-win32 code to
comp.compilers.lcc

Indeed.

 

[jacob navia]

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.

Hi Jean Pierre

The best is to use lcc under linux red hat. Please contact me for that.

Sorry to not answering you before but I was in holidays.

jacob

 

[Jean-Pierre Mestre]

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?

J-P.

 

[Richard Heathfield]

Jean-Pierre Mestre said:

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?

Yes. It's called "the ISO C Standard" or, more formally, ISO/IEC 9899.
Just about any C compiler you are likely to come across conforms to the
1990 version of that Standard. (There is a later version, 9899:1999,
but it is not (yet) recognised by all, or indeed more than a handful
of, compilers.)

 

[santosh]

Jean-Pierre Mestre wrote:

[top posting fixed]

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?

The C language as described by the ISO/IEC 9899:1990, known informally as
C89 or C90 or as ANSI C, is supported by pretty much every compiler out
there. If you stick to this subset, plus perhaps, the additions introduced
by Corrigenda 1 (1994), Amendment 1 (1995) and Corrigenda 2 (1996), then
your code is likely to be maximally portable.

The _current_ official C standard document is ISO/IEC 9899/1999, also called
C99, but full support for it confined to very few compilers. gcc supports a
large subset of it, while MSVC does not have any support at all.
Nevertheless, if your careful, you can use some features standardised by
it, that are widely implemented, like C++ style comments.

For obtaining a working draft of the next standard, which is essentially C99
plus TC1 and TC2, see:

<http://www.open-std.org/JTC1/SC22/WG14/>

See also <http://www.clc-wiki.net> for a draft of the C90 standard, which is
otherwise difficult to obtain.

 

[CBFalconer]

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 far as we can tell lcc-win32 is highly non-standard. Standard
C90 is accepted by virtually all C compilers (with some exceptions,
largely in the embedded world), and is the form of C discussed
here. The standard is easily available, in draft form as N869 or
N1124. A version of N869 slightly modified for easy reference and
quoting is available, bzip2 compressed, at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

 

[cr88192]

Jean-Pierre Mestre said:


Yes. It's called "the ISO C Standard" or, more formally, ISO/IEC 9899.
Just about any C compiler you are likely to come across conforms to the
1990 version of that Standard. (There is a later version, 9899:1999,
but it is not (yet) recognised by all, or indeed more than a handful
of, compilers.)

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 (to
what extent what one writes can be made portable...).


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

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.


my case, I have a compiler, it supports a subset of C (and also has a few
extensions). well, I don't have working static declarations and inline
functions as of yet, but I do have builtin geometric vectors and
quaternions, and other misc extension features...

note: the purpose of my compiler is not to compete with gcc, but to fill a
nice currently left void by gcc, that of being an at-runtime compiler (IMO,
a lot more powerful and useful than a typical script VM).


now, if in my compiler, I go and write code making use of a bunch of vector
and quaternion math using my extensions, well, then, it is not portable. I
still decided having them was worthwhile though.

also, apparently, unlike gcc I went and implemented imaginary types, having
failed to notice that gcc did not until generally afterwards. oh well...

or such...

 

[Richard Heathfield]

cr88192 said:

"Richard Heathfield" wrote...

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

(to what extent what one writes can be made portable...).

Some of us here in clc write portable code far more often than we write
non-portable code. It's certainly true of me, anyway.

<snip>

 

[Ian Collins]

Jean-Pierre Mestre wrote:

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.

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.

 

[jacob navia]

Jean-Pierre Mestre wrote:


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.

Most of the lcc-win32 extensions are very easily ported to C++

 

[Nick Keighley]

[C90]

C90 is good, yes...

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

and the rest

still, should work pretty good as a reference for writing portable code (to
what extent what one writes can be made portable...).

most of what I write is portable. And the non-portable bits can be put
in a separate module.

the standard explains more than a few things, but stops well short of a
complete explanation

that's what it's supposed to do...

(for example, of the exact calling conventions,

calling conventions!!! When do you need to know those? I've worked
on large systems (ok, lets just say fairly not-small). I've worked on
embedded systems. And I didn't need to know the calling conventions.
The last time I did was when there was no source code debugger so we
debugged the assembler. Great fun.

data representations,

how often do you need those? I like to have an "octet" (unsigned
8 bits) for external representation. But otherwise who cares?

... employed by an architecture, which may be particularly
relevant for more involved projects).

what are these "more involved projects"?

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

no no no!!!! Don't Do This!!! GCC is a particular implementation.
It can only tell you about GCC. Why not use the standard? You can
go a long way without getting implementation specific. I'm not
even sure what my current software is going to be targetted on
in the end. And mostly it doesn't matter.

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.

my case, I have a compiler, it supports a subset of C (and also has a few
extensions). well, I don't have working static declarations and inline
functions as of yet, but I do have builtin geometric vectors and
quaternions, and other misc extension features...
games?


note: the purpose of my compiler is not to compete with gcc, but to fill a
nice currently left void by gcc, that of being an at-runtime compiler (IMO,
a lot more powerful and useful than a typical script VM).

an interpreter or maybe a JIT compiler. Sounds cool.

now, if in my compiler, I go and write code making use of a bunch of vector
and quaternion math using my extensions, well, then, it is not portable. I
still decided having them was worthwhile though.

it's your language. If it solves problems for you then it's good.
Though you might have looked at things like Python, Perl, Tcl etc.
which might have already solved your problem.

also, apparently, unlike gcc I went and implemented imaginary types, having
failed to notice that gcc did not until generally afterwards. oh well...

or such...

<shrug> you have quaternions so you aren't trying to be standard C;
why worry about imaginary types. Hmmm imaginary types. You only think
you've stored your data but behind your back it mysteriously vanishes.
Didn't <large software company> implement that years ago?


--
Nick Keighley

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]

 

[Philip Potter]

Most of the lcc-win32 extensions are very easily ported to C++

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

 

[cr88192]

cr88192 said:

"Richard Heathfield" wrote...

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

Some of us here in clc write portable code far more often than we write
non-portable code. It's certainly true of me, anyway.

depends on the task probably.
for command-line based data-handling tools: yes, likely true.

for much more, errm, no.


I was assuming things with a little more going on (such as UIs, ...), and
this is where the problem lies...

now, one makes a tradeoff:
do I use OpenGL or DirectX.

GL is more portable than DX, and doing a GL-based UI is more portable than
the Win32 API.

after all, for GL and a GL-UI, it is mostly an option of GLX vs Win32 (for a
general setup and input-handling stub), but with DX or the Win32 API, we
have to replace the whole rendering pipeline or UI in order to port.

but, as soon as one goes anywhere near any of this, well then, strict
conformance with the C standard is broken (since, after all, C90 and C99 do
not include OpenGL as a part of the definition).

or, what if one needs dynamic code generation or scripting? well then, we
have a much bigger portability problem...

this is the problem really...

 

[cr88192]

[C90]

C90 is good, yes...

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

and the rest

still, should work pretty good as a reference for writing portable code
(to
what extent what one writes can be made portable...).

most of what I write is portable. And the non-portable bits can be put
in a separate module.

yes, a good practice.

I do similarly for the most part...

that's what it's supposed to do...



calling conventions!!! When do you need to know those? I've worked
on large systems (ok, lets just say fairly not-small). I've worked on
embedded systems. And I didn't need to know the calling conventions.
The last time I did was when there was no source code debugger so we
debugged the assembler. Great fun.

in what I do, this I need to know.

how often do you need those? I like to have an "octet" (unsigned
8 bits) for external representation. But otherwise who cares?

it matters...

what are these "more involved projects"?

lots of things...

no no no!!!! Don't Do This!!! GCC is a particular implementation.
It can only tell you about GCC. Why not use the standard? You can
go a long way without getting implementation specific. I'm not
even sure what my current software is going to be targetted on
in the end. And mostly it doesn't matter.

gcc tells about gcc, and in many cases, very important pieces on info, like
the further specifics of the calling convention, the structure of the
generated code, ...

games?

well, I also wrote a 3D modeler and skeletal animation tools, a physics
engine, ...
vectors are pretty basic and useful.

an interpreter or maybe a JIT compiler. Sounds cool.

technically, it is neither.
my previous script langs were interpreters.
my last VM was JIT based.

my C compiler works much closer to a traditional compiler, but at runtime.

http://en.wikipedia.org/wiki/Incremental_compiler

it's your language. If it solves problems for you then it's good.
Though you might have looked at things like Python, Perl, Tcl etc.
which might have already solved your problem.

I have complaints, I no longer like interpreter or VM-based languages, for
some fundamental limitations in the existence of a VM.

a more 'involved' approach (a full-on compiler) can get around these
problems.


for example, almost no traditional VM around lets you be like:
well, here is some static library, and some header files, I feel like going
and merging these into the running process image and hacking them into the
running app's code...

but, now, I can...


instead, any such lib has to be linked with the host app, and one has to go
through the pain of getting some or another FFI interface to work.

in my case, there is no FFI, things work directly...

<shrug> you have quaternions so you aren't trying to be standard C;
why worry about imaginary types. Hmmm imaginary types. You only think
you've stored your data but behind your back it mysteriously vanishes.
Didn't <large software company> implement that years ago?

well, I am working on getting it close, though yes, being a strictly
conformant implementation is not needed in my case.

well, they are extensions, they require a header (otherwise they have ugly
built-in names...).

--
Nick Keighley

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]

 

[Ben Bacarisse]

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.