porting issues ?

Discussion in 'C Programming' started by navin_2016, Dec 8, 2003.

  1. navin_2016

    navin_2016 Guest

    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
    -
    navin_2016, Dec 8, 2003
    #1
    1. Advertising

  2. "navin_2016" <> schrieb im Newsbeitrag
    news:...
    > 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 ?


    There should be no problem as long as you strictly adhere to the C standard
    (which is seldom possible).
    If you put nonstandard stuff into separate compilation units, porting will
    at least be easier than if you mix standard and nonstandard things
    everywhere.

    > 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
    > -
    Robert Stankowic, Dec 8, 2003
    #2
    1. Advertising

  3. navin_2016

    CBFalconer Guest

    navin_2016 wrote:
    >
    > 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 ?


    If you adhere to the C standard, you should have no problems with
    any of those, barring the use of binary files created or used by
    other systems. That you can avoid by using text.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Dec 8, 2003
    #3
  4. CBFalconer wrote:

    >
    > If you adhere to the C standard, you should have no problems with
    > any of those, barring the use of binary files created or used by
    > other systems. That you can avoid by using text.
    >


    Could you explain what specific problems you are referring to with
    respect to binary files?

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Dec 8, 2003
    #4
  5. navin_2016

    nrk Guest

    Kevin Goodsell wrote:

    > CBFalconer wrote:
    >
    >>
    >> If you adhere to the C standard, you should have no problems with
    >> any of those, barring the use of binary files created or used by
    >> other systems. That you can avoid by using text.
    >>

    >
    > Could you explain what specific problems you are referring to with
    > respect to binary files?
    >
    > -Kevin


    One problem that comes to mind is reading/writing using fread/fwrite
    (structs, ints, floats etc.)...

    -nrk.
    nrk, Dec 8, 2003
    #5
  6. navin_2016

    Eric Sosman Guest

    Kevin Goodsell wrote:
    >
    > CBFalconer wrote:
    >
    > >
    > > If you adhere to the C standard, you should have no problems with
    > > any of those, barring the use of binary files created or used by
    > > other systems. That you can avoid by using text.
    > >

    >
    > Could you explain what specific problems you are referring to with
    > respect to binary files?


    For starters, see Question 20.5 in the comp.lang.c
    Frequently Asked Questions (FAQ) list

    http://www.eskimo.com/~scs/C-faq/top.html

    .... and don't forget to follow the links you'll find there.

    --
    Eric Sosman, Dec 8, 2003
    #6
  7. nrk wrote:

    > Kevin Goodsell wrote:
    >
    >
    >>CBFalconer wrote:
    >>
    >>
    >>>If you adhere to the C standard, you should have no problems with
    >>>any of those, barring the use of binary files created or used by
    >>>other systems. That you can avoid by using text.
    >>>

    >>
    >>Could you explain what specific problems you are referring to with
    >>respect to binary files?
    >>
    >>-Kevin

    >
    >
    > One problem that comes to mind is reading/writing using fread/fwrite
    > (structs, ints, floats etc.)...
    >


    Yes, but neither Chuck nor I would do that.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Dec 8, 2003
    #7
  8. navin_2016

    CBFalconer Guest

    Kevin Goodsell wrote:
    > CBFalconer wrote:
    >
    > > If you adhere to the C standard, you should have no problems with
    > > any of those, barring the use of binary files created or used by
    > > other systems. That you can avoid by using text.

    >
    > Could you explain what specific problems you are referring to with
    > respect to binary files?


    For example, endianness, sizeof various entities, value of
    CHAR_BIT, etc.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Dec 8, 2003
    #8
  9. CBFalconer wrote:

    > Kevin Goodsell wrote:
    >
    >>
    >>Could you explain what specific problems you are referring to with
    >>respect to binary files?

    >
    >
    > For example, endianness, sizeof various entities, value of
    > CHAR_BIT, etc.
    >


    The only one of those that seems like a serious problem to me is
    CHAR_BIT. Byte-order and the number of bytes for a given field would be
    determined by the file format, which must be agreed upon by both sides
    regardless of whether it's text or binary.

    But, if the source and destination machine use different byte-sizes, I'm
    not sure what you'd do, partly because I don't know how the file would
    be translated. Obviously a file with 9-bit bytes moved to a machine with
    8-bit bytes needs to be converted somehow. Suppose the conversion
    consists of throwing away the high-order bit for each byte. In that
    case, you just make sure you don't use that bit - limit yourself to the
    8-bit range for each byte.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Dec 9, 2003
    #9
  10. navin_2016

    Jack Klein Guest

    On Mon, 08 Dec 2003 23:19:16 GMT, CBFalconer <>
    wrote in comp.lang.c:

    > Kevin Goodsell wrote:
    > > CBFalconer wrote:
    > >
    > > > If you adhere to the C standard, you should have no problems with
    > > > any of those, barring the use of binary files created or used by
    > > > other systems. That you can avoid by using text.

    > >
    > > Could you explain what specific problems you are referring to with
    > > respect to binary files?

    >
    > For example, endianness, sizeof various entities, value of
    > CHAR_BIT, etc.


    I'm curious, Chuck, because I know you're a long time embedded systems
    programmer with experience on many different architectures, as I am.

    Have you ever worked on a platform where CHAR_BIT was NOT 8? I've
    done some Analog Devices SHARC work where CHAR_BIT was 32, and I'm
    doing a lot of work on a TI 2812 DSP right now where CHAR_BIT is 16.

    If you have worked on platforms where CHAR_BIT was greater than 8,
    have they always had signed and unsigned char having the same
    representation as signed and unsigned int (if not also signed and
    unsigned long)?

    Note that many standard functions, particularly all FILE * streams,
    are impossible to implement on a platform where UCHAR_MAX == UINT_MAX,
    since all file input if built on fgetc(), which can return any
    unsigned character value from 0 to UCHAR_MAX, and EOF which must be a
    negative integer and have a recognizably different bit pattern from
    the above.

    As for dealing with data internally on platforms with CHAR_BIT > 8,
    it's not really all that hard. All the code in my chapter of C
    Unleashed is "CHAR_BIT > 8" safe, because you only use the 8 least
    significant bits an unsigned char and ignore anything else.

    In the real world, I recently wrote both ends of a parser/formatter
    for a proprietary CAN bus protocol. CAN messages (as you probably
    know, but others might not) contain between 0 and 64 bits of data,
    packed into 0 to 8 octets of 8 bits each.

    My parser and formatter can pack and unpack various 8, 16, and 32 bit
    values from any possible starting point in the data field of such a
    packet into a signed or unsigned 8, 16, or 32 bit data object.

    Since the processor on one side of the protocol was a TI DSP with
    CHAR_BIT 16, it was written with "CHAR_BIT > 8" portability in mind.
    The resultant source code compiles and runs properly both on the DSP
    and on the other end of the CAN bus, where the ARM processor does have
    8 bit character types.

    There is only one tiny bit of surplus code to achieve that
    portability. At one point there is an expression where an unsigned
    char value is updated like this:

    uc = (uc << 2) & 0xff;

    ....the mask is unnecessary when CHAR_BIT is 8 but is necessary on the
    DSP because other parts of the code require all bits above 8 in the
    unsigned char (if any) always be 0.

    The value of CHAR_BIT is not much of a deterrent to portable code if
    you give it a little thought and avoid using more than 8 of them even
    when they are available.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Dec 9, 2003
    #10
  11. navin_2016

    navin_2016 Guest

    Kevin Goodsell <> wrote in message news:<2A5Bb.5952$>...
    > CBFalconer wrote:
    >
    > >
    > > If you adhere to the C standard, you should have no problems with
    > > any of those, barring the use of binary files created or used by
    > > other systems. That you can avoid by using text.
    > >

    >
    > Could you explain what specific problems you are referring to with
    > respect to binary files?
    >
    > -Kevin


    I am trying to learn this thing. This is a hypothetical situtation.
    I want to read an APPLE disk raw mode connected to an intel processor.
    What are the issues that has to be handled.

    Navin
    -
    navin_2016, Dec 9, 2003
    #11
  12. navin_2016

    CBFalconer Guest

    Jack Klein wrote:
    >

    .... snip ...
    >
    > I'm curious, Chuck, because I know you're a long time embedded systems
    > programmer with experience on many different architectures, as I am.
    >
    > Have you ever worked on a platform where CHAR_BIT was NOT 8? I've
    > done some Analog Devices SHARC work where CHAR_BIT was 32, and I'm
    > doing a lot of work on a TI 2812 DSP right now where CHAR_BIT is 16.
    >

    .... snip ...
    >
    > The value of CHAR_BIT is not much of a deterrent to portable code if
    > you give it a little thought and avoid using more than 8 of them even
    > when they are available.


    No, I haven't actually run into the problem. But I see no reason
    to ignore it (not that I am suggesting you do).

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Dec 9, 2003
    #12
  13. navin_2016

    Grumble Guest

    Kevin Goodsell wrote:
    > But, if the source and destination machine use different
    > byte-sizes, I'm not sure what you'd do, partly because I don't
    > know how the file would be translated. Obviously a file with
    > 9-bit bytes moved to a machine with 8-bit bytes needs to be
    > converted somehow.


    Can somebody name one or more processors manufactured in 2003 where
    CHAR_BIT is *not* a power of 2?
    Grumble, Dec 9, 2003
    #13
  14. navin_2016

    Flash Gordon Guest

    On 8 Dec 2003 21:05:56 -0800
    (navin_2016) wrote:

    > Kevin Goodsell <> wrote in message
    > news:<2A5Bb.5952$>...
    > > CBFalconer wrote:
    > >
    > > > If you adhere to the C standard, you should have no problems with
    > > > any of those, barring the use of binary files created or used by
    > > > other systems. That you can avoid by using text.

    > >
    > > Could you explain what specific problems you are referring to with
    > > respect to binary files?

    >
    > I am trying to learn this thing. This is a hypothetical situtation.
    > I want to read an APPLE disk raw mode connected to an intel processor.
    > What are the issues that has to be handled.


    Raw disk access is a separate topic from binary file access. The
    standard defines ways of handling binary files, but does not define ANY
    way of doing raw disk access.

    <OT>
    In practical terms, it is completely impossible to read some disks on an
    x86 platform with a typical BIOS unless you talk directly to the disk
    controller. Even then, disks from some systems will be completely
    unreadable as they use a different low level format. So you would need
    to work out exactly what you want to do and ask somewhere else.
    </OT>
    --
    Mark Gordon
    Paid to be a Geek & a Senior Software Developer
    Although my email address says spamtrap, it is real and I read it.
    Flash Gordon, Dec 9, 2003
    #14
  15. navin_2016

    Dan Pop Guest

    In <Kr6Bb.4340$> Kevin Goodsell <> writes:

    >nrk wrote:
    >
    >> Kevin Goodsell wrote:
    >>
    >>>CBFalconer wrote:
    >>>
    >>>>If you adhere to the C standard, you should have no problems with
    >>>>any of those, barring the use of binary files created or used by
    >>>>other systems. That you can avoid by using text.
    >>>>
    >>>Could you explain what specific problems you are referring to with
    >>>respect to binary files?
    >>>
    >>>-Kevin

    >>
    >> One problem that comes to mind is reading/writing using fread/fwrite
    >> (structs, ints, floats etc.)...

    >
    >Yes, but neither Chuck nor I would do that.


    That's highly irrelevant. The user has done that and you must write a
    program to process his data.

    And there are perfectly good reasons for writing binary files this
    way, especially when size does matter. Just document the format of
    each binary item in the file.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Dec 9, 2003
    #15
  16. navin_2016

    Dan Pop Guest

    In <rR9Bb.6270$> Kevin Goodsell <> writes:

    >CBFalconer wrote:
    >
    >> Kevin Goodsell wrote:
    >>
    >>>
    >>>Could you explain what specific problems you are referring to with
    >>>respect to binary files?

    >>
    >>
    >> For example, endianness, sizeof various entities, value of
    >> CHAR_BIT, etc.
    >>

    >
    >The only one of those that seems like a serious problem to me is
    >CHAR_BIT.


    There was only one known platform with a conforming hosted
    implementation having CHAR_BIT != 8. If portability to real world
    hosted implementations is a concern, CHAR_BIT is the last thing I would
    worry about.

    The most important one is probably the very limited I/O capabilities
    provided by standard C that effectively force people to use platform
    specific extensions for both functionality and security related reasons.

    As we all know, even something as trivial as suppressing terminal echo
    or checking the availability of input in stdin are insoluble problems in
    standard C.

    >Byte-order and the number of bytes for a given field would be
    >determined by the file format, which must be agreed upon by both sides
    >regardless of whether it's text or binary.


    If it's text, all you have to agree upon is a field separator and
    optionally a maximum field length (useful to detect garbage input).
    And a character set, of course :)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Dec 9, 2003
    #16
  17. navin_2016

    Dan Pop Guest

    In <br4496$her$> Grumble <> writes:

    >Kevin Goodsell wrote:
    >> But, if the source and destination machine use different
    >> byte-sizes, I'm not sure what you'd do, partly because I don't
    >> know how the file would be translated. Obviously a file with
    >> 9-bit bytes moved to a machine with 8-bit bytes needs to be
    >> converted somehow.

    >
    >Can somebody name one or more processors manufactured in 2003 where
    >CHAR_BIT is *not* a power of 2?


    Do a Google search for "24-bit dsp". But the important thing is that
    there are no hosted implementations for such processors.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Dec 9, 2003
    #17
  18. navin_2016

    Dan Pop Guest

    In <> (navin_2016) writes:

    >I am trying to learn this thing. This is a hypothetical situtation.
    >I want to read an APPLE disk raw mode connected to an intel processor.
    >What are the issues that has to be handled.


    Everything related to transferring the bytes from the disk to the memory.

    Once you have the bytes in memory, you can process them with portable C
    code (if you know what to do with them).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Dec 9, 2003
    #18
  19. (Dan Pop) writes:
    [...]
    > There was only one known platform with a conforming hosted
    > implementation having CHAR_BIT != 8. If portability to real world
    > hosted implementations is a concern, CHAR_BIT is the last thing I would
    > worry about.


    Really? What platform is it? (I presume you're not talking about the
    DS9000.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    (Note new e-mail address)
    Keith Thompson, Dec 9, 2003
    #19
  20. navin_2016

    Dan Pop Guest

    In <> Keith Thompson <> writes:

    > (Dan Pop) writes:
    >[...]
    >> There was only one known platform with a conforming hosted
    >> implementation having CHAR_BIT != 8. If portability to real world
    >> hosted implementations is a concern, CHAR_BIT is the last thing I would
    >> worry about.

    >
    >Really? What platform is it? (I presume you're not talking about the
    >DS9000.)


    The C89 implementation for the Univac 1100 (or something like that) had
    9-bit char's and it was also (in)famous for using one's complement
    arithmetic.

    Such characteristics were not exactly uncommon once upon a time, but this
    is the only such hardware platform with a C89 implementation that I'm
    aware of.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Dec 10, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Overworked

    HELP - Porting to .NET path?

    Overworked, Jan 23, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    381
    Chad Z. Hower aka Kudzu
    Jan 23, 2004
  2. Nate
    Replies:
    2
    Views:
    413
    Yan-Hong Huang[MSFT]
    Feb 18, 2004
  3. DevBoy
    Replies:
    0
    Views:
    332
    DevBoy
    May 6, 2004
  4. Bijoy Naick

    Porting over an ASP.NET application

    Bijoy Naick, May 6, 2004, in forum: ASP .Net
    Replies:
    6
    Views:
    416
    Curt_C [MVP]
    May 10, 2004
  5. Deron Meranda
    Replies:
    0
    Views:
    213
    Deron Meranda
    Oct 5, 2012
Loading...

Share This Page