This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

this is non portable code ?


unsigned char buf[100]
.
.
.
unsigned int val;
.
.
.
val = *((unsigned int *)(&buf[1]));
.
.
.

comments?

Parents
  • Of course, were I to 'verify' my assumption that a char is 8 bits every time I type char, I would never get anywhere.

    In reality, you have to. But you don't have to do it exactly when you write the 'char' keyword. But you - at least - have to verify it when you select a new processor or a new compiler. I don't expect one of my existing compilers to change that behaviour - at least not without adding a very visible note in the release notes :)

    Luckily, no chip manufacturer dares to step away från n*8-sized integer data types, because of the very bad feedback they would get from all the people who made the incorrect assumption that their programs will not fail if run on a machine with a 7-bit or 9-bit char data type. If they do add unusual data types, they add them as complements to more standard data types.

    One of the first things you should do when looking for a new compiler, is to get your hands on the documentation about their take on the implementation-specific parts of the standard. You want to know if there are significant limits in # of nested if statements, number of case statements in a switch, if you will be able to nest multiple include files, if they have the usual include files (complete with expected contents) etc.

    In the same way, you have to make sure if a selected processor has a general stack implementation, or if it may have a hard-coded return stack with a limited # of return etnries. You want to know if it can index data - and to what degree. You want to know if it will glow like Chernobyl or if it has reasonable power-save modes. Some details you will look up. Some details you will forget to look up. Some details you will assume to be ok, and will ignore checking up on. Checking up on everything requires perfect documentation, perfect memory and almost infinite amounts of time.

Reply
  • Of course, were I to 'verify' my assumption that a char is 8 bits every time I type char, I would never get anywhere.

    In reality, you have to. But you don't have to do it exactly when you write the 'char' keyword. But you - at least - have to verify it when you select a new processor or a new compiler. I don't expect one of my existing compilers to change that behaviour - at least not without adding a very visible note in the release notes :)

    Luckily, no chip manufacturer dares to step away från n*8-sized integer data types, because of the very bad feedback they would get from all the people who made the incorrect assumption that their programs will not fail if run on a machine with a 7-bit or 9-bit char data type. If they do add unusual data types, they add them as complements to more standard data types.

    One of the first things you should do when looking for a new compiler, is to get your hands on the documentation about their take on the implementation-specific parts of the standard. You want to know if there are significant limits in # of nested if statements, number of case statements in a switch, if you will be able to nest multiple include files, if they have the usual include files (complete with expected contents) etc.

    In the same way, you have to make sure if a selected processor has a general stack implementation, or if it may have a hard-coded return stack with a limited # of return etnries. You want to know if it can index data - and to what degree. You want to know if it will glow like Chernobyl or if it has reasonable power-save modes. Some details you will look up. Some details you will forget to look up. Some details you will assume to be ok, and will ignore checking up on. Checking up on everything requires perfect documentation, perfect memory and almost infinite amounts of time.

Children
  • But you - at least - have to verify it when you select a new processor or a new compiler.
    Of, course; however, I wrote "every time"

    Luckily, no chip manufacturer dares to step away från n*8-sized integer data types, because of the very bad feedback they would get from all the people who made the incorrect assumption that their programs will not fail if run on a machine with a 7-bit or 9-bit char data type. If they do add unusual data types, they add them as complements to more standard data types.
    I would not know about chips, but Univac and (some) DEC machines use 6 bit bytes.

    Erik

    PS "från" slipped into your post, do you write in Swedish first or did a word just slip in ?

  • No two-step translation involved. However, I sometimes gets parity bit errors - especially when someone comes in and wants to talk to me in the middle of writing :)

    Sw: från = Eng: from. They start the same, the same number of letters and similar pronounciation.

    IBM had 36-bit big iron, so they impplemented 4x 9-bit characters or 5x 7-bit characters.

  • Control Data Corporation's "Cyber" machines used 6-bit characters and a 60-bit word. The OS had a special "ASCII" mode that translated files with special multi-byte escape sequences to represent both upper and lower case. Writing character values in octal actually made sense for this machine.