We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
unsigned char buf[100] . . . unsigned int val; . . . val = *((unsigned int *)(&buf[1])); . . .
comments?
been there, done that, and, even worse
That comes as no surprise.
It is nice that you see that I have a lot of experience.
If, on the other hand, you were trying to belittle me, you must have missed "BTW the 'error' was not mine, it occurred ... in my post.
Er5ik
Sadly you do seem to have a lot of experience of bugs which you should never have introduced into the code in the first place. Your assumption when something doesn't work as you expect is that the problem lies with the tools - this is quite typical of those who (as you admit openly, in fact you seem proud of it) haven't read the appropriate documentation.
Note that in this case the 'tool' is the 'C' language, and the 'appropriate documentation' is the definition of the language.
you must have missed "BTW the 'error' was not mine, it occurred ... in my post.
Yes, I noticed you try to salvage some credibility in a followup post.
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.
Sadly you do seem to have a lot of experience of bugs which you should never have introduced into the code in the first place. When being a member of groups, I have most often been "the debugger" thus your uttely stupid assumption that bugs I have seen were those I "have introduced into the code in the first place" is completely false.
Your assumption when something doesn't work as you expect is that the problem lies with the tools Where on earth did you get that impression? Of course in a toolmakers forum tools are the main subject of discussion, it evidently takes a smoked sardine to ASS U ME that limiting a discussion to the subject means that there are no other subjects.
Erik
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.
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.