|
Home > Archive > Unix Programming > January 2004 > porting software
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| navin_2016 2004-01-23, 5:05 pm |
| Hi,
Can somone please describe the problems one would face when we try
to port a software written in C to another platform some of them being
endianness ,alignment,data types etc ?
It would be very helpful if you could state the solution along with
problem .Also can you please give me some pointers and links to
documents so that porting can be easily accomplished ?
Navin
-
| |
| Jerry Feldman 2004-01-23, 5:05 pm |
| On 8 Dec 2003 04:52:31 -0800
navin_2013@yahoo.co.in (navin_2016) wrote:
quote:
> Hi,
> Can somone please describe the problems one would face when we try
> to port a software written in C to another platform some of them being
> endianness ,alignment,data types etc ?
>
> It would be very helpful if you could state the solution along with
> problem .Also can you please give me some pointers and links to
> documents so that porting can be easily accomplished ?
There are many porting guides written by vendors. For instance each
vendor maintains these guides to help developers port to their platform.
For instance HP has a large number of porting guides both to HP-UX as
well as to Tru64 Unix.
http://www.hp.com/ Search on porting.
When Compaq was acquired by HP, we wrote the Tur64 Unix to HP-UX porting
guide.
While the C language is generally portable if you stick to the standard
and the FAQ, there are many system calls and library functions that are
outside of the C standard. Unix itself has some different standards.
Some Unixes are System V and use the SVID standards and some are BSD and
use the X/Open standards (eg. Unix 95 and Unix 98).
And, as you mentioned, endianness can be one problem if you rely on bit
positions, and porting to a 64 bit platform can also be a challenge
because so many programmers have (erroneously) relied on 32 bitness.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
| |
| Jerry Feldman 2004-01-23, 5:05 pm |
| On 8 Dec 2003 04:52:31 -0800
navin_2013@yahoo.co.in (navin_2016) wrote:
quote:
> Hi,
> Can somone please describe the problems one would face when we try
> to port a software written in C to another platform some of them being
> endianness ,alignment,data types etc ?
>
> It would be very helpful if you could state the solution along with
> problem .Also can you please give me some pointers and links to
> documents so that porting can be easily accomplished ?
There are many porting guides written by vendors. For instance each
vendor maintains these guides to help developers port to their platform.
For instance HP has a large number of porting guides both to HP-UX as
well as to Tru64 Unix.
http://www.hp.com/ Search on porting.
When Compaq was acquired by HP, we wrote the Tur64 Unix to HP-UX porting
guide.
While the C language is generally portable if you stick to the standard
and the FAQ, there are many system calls and library functions that are
outside of the C standard. Unix itself has some different standards.
Some Unixes are System V and use the SVID standards and some are BSD and
use the X/Open standards (eg. Unix 95 and Unix 98).
And, as you mentioned, endianness can be one problem if you rely on bit
positions, and porting to a 64 bit platform can also be a challenge
because so many programmers have (erroneously) relied on 32 bitness.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
| |
| Mohun Biswas 2004-01-23, 5:05 pm |
| Jerry Feldman wrote:quote:
> While the C language is generally portable if you stick to the standard
> and the FAQ, there are many system calls and library functions that are
> outside of the C standard. Unix itself has some different standards.
> Some Unixes are System V and use the SVID standards and some are BSD and
> use the X/Open standards (eg. Unix 95 and Unix 98).
On this subject ... I've often wished for a "reverse directory" of C
library functions. I.e. one could memorize the ANSI C standard(s) and
POSIX and SUS etc. in order to know whether function xyz() belongs to
one or the other, just as one could memorize the phone book, but
sometimes (often) I'm thinking of using xyz() and want to know how
standard it is first. A basic list with API's in the left column and
applicable standards on the right, with perhaps notations along the
lines of "basics covered by ANSI C, extended functionality described by
POSIX", would be the ideal. Anyone know of such a thing?
M.B.
| |
| Mohun Biswas 2004-01-23, 5:05 pm |
| Jerry Feldman wrote:quote:
> While the C language is generally portable if you stick to the standard
> and the FAQ, there are many system calls and library functions that are
> outside of the C standard. Unix itself has some different standards.
> Some Unixes are System V and use the SVID standards and some are BSD and
> use the X/Open standards (eg. Unix 95 and Unix 98).
On this subject ... I've often wished for a "reverse directory" of C
library functions. I.e. one could memorize the ANSI C standard(s) and
POSIX and SUS etc. in order to know whether function xyz() belongs to
one or the other, just as one could memorize the phone book, but
sometimes (often) I'm thinking of using xyz() and want to know how
standard it is first. A basic list with API's in the left column and
applicable standards on the right, with perhaps notations along the
lines of "basics covered by ANSI C, extended functionality described by
POSIX", would be the ideal. Anyone know of such a thing?
M.B.
| |
| Pascal Bourguignon 2004-01-23, 5:05 pm |
| Mohun Biswas <m.biswas@invalid.addr> writes:
quote:
> Jerry Feldman wrote:
>
> On this subject ... I've often wished for a "reverse directory" of C
> library functions. I.e. one could memorize the ANSI C standard(s) and
> POSIX and SUS etc. in order to know whether function xyz() belongs to
> one or the other, just as one could memorize the phone book, but
> sometimes (often) I'm thinking of using xyz() and want to know how
> standard it is first. A basic list with API's in the left column and
> applicable standards on the right, with perhaps notations along the
> lines of "basics covered by ANSI C, extended functionality described
> by POSIX", would be the ideal. Anyone know of such a thing?
Like we say in French: man, that's not for the dogs!
man fopen
....
CONFORMING TO
The fopen and freopen functions conform to ANSI X3.159-1989
(``ANSI C''). The fdopen function conforms to IEEE
Std1003.1-1988 (``POSIX.1'').
....
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
* . . /\ () . *
Living free in Alaska or in Siberia, a . . / .\ . * .
grizzli's life expectancy is 35 years, .*. / * \ . .
but no more than 8 years in captivity. . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: postmaster@sco.com ******************
| |
| Pascal Bourguignon 2004-01-23, 5:05 pm |
| Mohun Biswas <m.biswas@invalid.addr> writes:
quote:
> Jerry Feldman wrote:
>
> On this subject ... I've often wished for a "reverse directory" of C
> library functions. I.e. one could memorize the ANSI C standard(s) and
> POSIX and SUS etc. in order to know whether function xyz() belongs to
> one or the other, just as one could memorize the phone book, but
> sometimes (often) I'm thinking of using xyz() and want to know how
> standard it is first. A basic list with API's in the left column and
> applicable standards on the right, with perhaps notations along the
> lines of "basics covered by ANSI C, extended functionality described
> by POSIX", would be the ideal. Anyone know of such a thing?
Like we say in French: man, that's not for the dogs!
man fopen
....
CONFORMING TO
The fopen and freopen functions conform to ANSI X3.159-1989
(``ANSI C''). The fdopen function conforms to IEEE
Std1003.1-1988 (``POSIX.1'').
....
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
* . . /\ () . *
Living free in Alaska or in Siberia, a . . / .\ . * .
grizzli's life expectancy is 35 years, .*. / * \ . .
but no more than 8 years in captivity. . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: postmaster@sco.com ******************
| |
| Jerry Feldman 2004-01-23, 5:06 pm |
| On Mon, 08 Dec 2003 14:20:04 GMT
Mohun Biswas <m.biswas@invalid.addr> wrote:
quote:
> Jerry Feldman wrote:
>
> On this subject ... I've often wished for a "reverse directory" of C
> library functions. I.e. one could memorize the ANSI C standard(s) and
> POSIX and SUS etc. in order to know whether function xyz() belongs to
> one or the other, just as one could memorize the phone book, but
> sometimes (often) I'm thinking of using xyz() and want to know how
> standard it is first. A basic list with API's in the left column and
> applicable standards on the right, with perhaps notations along the
> lines of "basics covered by ANSI C, extended functionality described
> by POSIX", would be the ideal. Anyone know of such a thing?
One thing that becomes fun is when there are conflicting standards. I
was reposnsible for the math library for a while for Tru64 Unix. We ran
into problems where the SVID and the XOpen standards were in conflict,
mainly on the errno value. We would release compliant to one standard,
and the other internal QA group would file a show stopper. The solution
was to get a waiver from SVID.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
| |
| Jerry Feldman 2004-01-23, 5:06 pm |
| On Mon, 08 Dec 2003 14:20:04 GMT
Mohun Biswas <m.biswas@invalid.addr> wrote:
quote:
> Jerry Feldman wrote:
>
> On this subject ... I've often wished for a "reverse directory" of C
> library functions. I.e. one could memorize the ANSI C standard(s) and
> POSIX and SUS etc. in order to know whether function xyz() belongs to
> one or the other, just as one could memorize the phone book, but
> sometimes (often) I'm thinking of using xyz() and want to know how
> standard it is first. A basic list with API's in the left column and
> applicable standards on the right, with perhaps notations along the
> lines of "basics covered by ANSI C, extended functionality described
> by POSIX", would be the ideal. Anyone know of such a thing?
One thing that becomes fun is when there are conflicting standards. I
was reposnsible for the math library for a while for Tru64 Unix. We ran
into problems where the SVID and the XOpen standards were in conflict,
mainly on the errno value. We would release compliant to one standard,
and the other internal QA group would file a show stopper. The solution
was to get a waiver from SVID.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
| |
| Bjorn Reese 2004-01-23, 5:06 pm |
| On Mon, 08 Dec 2003 14:20:04 +0000, Mohun Biswas wrote:
quote:
> standard it is first. A basic list with API's in the left column and
> applicable standards on the right, with perhaps notations along the
http://petef.port5.com/c/portability.txt
--
mail1dotstofanetdotdk
| |
| Bjorn Reese 2004-01-23, 5:06 pm |
| On Mon, 08 Dec 2003 14:20:04 +0000, Mohun Biswas wrote:
quote:
> standard it is first. A basic list with API's in the left column and
> applicable standards on the right, with perhaps notations along the
http://petef.port5.com/c/portability.txt
--
mail1dotstofanetdotdk
|
|
|
|
|