shame on MISRA

Chris Hills escribió:

IIRC, EN-50128 (similar to IEC 61508, but for railway systems), states C as R for SIL 3-4, but C with an enforced safe subset as HR.

Reply to
Ignacio G.T.
Loading thread data ...

1993/4/5/6 depending which copy you have.

Lots of people did.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Ignacio G.T. writes

It is similar to the 61508 table. I have just had a look a both.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Was there any reason not to just use 0xffffU ? I don't recall ever having a problem with that.

B
Reply to
Brian Gaughan

... snip ...

Because you don't know the size of the variable, nor the arithmetic scheme. That's why -1.

--
 
 
 Click to see the full signature
Reply to
CBFalconer

(**) Sufficiently motivated developer can screw any rules. It does not mean the rules are bad, it means the developer shall be fired.

It depends on the negative number representation on the target system. It is an unprofessional programming practice bordering with the sabotage.

This is exactly what one shall do.

See (**) above.

Exactly.

--
"Liberalism is a mental disorder"
Reply to
Yuriy

Reading C standard once in a while is highly recommended.

ISO/IEC 9899

6.2.6.2 Integer types

If the sign bit is zero, it shall not affect the resulting value. If the sign bit is one, the value shall be modified in one of the following ways:

- the corresponding value with sign bit 0 is negated (sign and magnitude);

- the sign bit has the value -(2N) (two's complement);

- the sign bit has the value -(2N - 1) (one's complement). Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one's complement), is a trap representation or a normal value. In the case of sign and magnitude and one's complement, if this representation is a normal value it is called a negative zero.

--
"Liberalism is a mental disorder"
Reply to
Yuriy

Not quite. Somehow the discussion has changed to the representation of ~1 rather than ~0.

~0U is still an all-ones pattern, and -1 converted to unsigned is too. At least according to C99. MISRA may impose extra limitations to what is considered safe.

Reply to
Arlet

...

Then it's the same as using 0xffffffff to have all 1s. Shortly- IMO it depends on what do you want to have. If you need 0xffff then you should use 0xffff. If you need all 1s, then using 0xffff is, IMO, bad practice because it won't give you all 1s, only 16 of them.

I disagree as long, as your intention is to have all 1s there.

1) You will be forced to count Fs (simple test reveals, that most people can't see how many Fs there are in a row if there are more than 6 of them- they _assume_ there are 8, because 'it looks like it'- they count them at the last resort. Just ask your peers), 2) If you ever happen to change your uint16_t to uint32_t or uint64_t (uC change, performance tuning- for example ARM works faster with uint32_t than with uint16_t), the ~0 will still put all 1s there, whilst 0xffff or 0xfffffffff won't. Then you have a maintenance issue. And no checking tool or compiler is going to warn you.

M.

Reply to
Marcin Wolcendorf

It doesn't. Because the semantics of the unary minus operator on an unsigned number are well-defined.

No, it's not, because there's nothing keeping an unsigned int from having more bits than there are 1-bits in 0xffffffff.

Shortly- IMO it

And 0xffffffff is bad practice for exactly the same reason: it gives you only 32 of them. That may seem sufficient, but ultimately it's not.

... as will -1

Reply to
Hans-Bernhard Bröker

While I'm not in it _just_ for the money, if there wasn't _any_ money I wouldn't be working here because without an income I'd have nowhere to come home to, no means of travelling there, and nothing to eat when I arrived; I hypothesize that this is the case for many. Therefore the opinion of the boss (note: mine is _not_ of this type) who says "That's wasting time; just Make It Work today" has to carry a little weight, and compromises are made somewhere.

Any discussion on how those compromises can be tweaked to fall in the direction of better code will surely be welcome here.

Unless you are making a job offer, this is a politician's promise.

It's telling, here, that you originally quoted Marcin's question but did not reply to it. That suggests that you have the freedom to not worry about income, and perhaps even consider the question of money to be beneath you. How nice for you.

mlp

Reply to
Mark L Pappin

6.2.6.2 talks about representation of types. That ist, it describes what you get if you do int i = -1; unsigned u = *(unsigned*) &i; For a sign/magnitude system, this may yield u = 0x8001.

For 'unsigned u = -1', you want 6.3.1.3, which says that -1 converted to unsigned always yields an "all-one-bits" pattern, i.e. 0xffff. This is the same in C89 (which has this rule in 3.2.1.2) and C++98 (4.7), so I would consider this a pretty safe guarantee. And it does mean that a sign/magnitude machine has to do a little bit more than just copying the bit representation from one variable to another.

Stefan

Reply to
Stefan Reuther

~1? I read Marcin to be asking whether ~0 won't set all 1s.

--
Dan Henry
Reply to
Dan Henry

... snip ...

~ 0 ---> ~0x0000 ---> 0xffff "

~ 0 ---> ~0x0000 ---> 0xffff " or ~ 0 ---> ~0xffff ---> 0x0000 "

~ 0 ---> ~0x0000 ---> 0xffff "

See the additions above. Only -1 always returns 0xffff.

--
 
 
 Click to see the full signature
Reply to
CBFalconer

Isn't the integer constant 0 (lacking the unary - operator) in a 1's complement system positive zero, not negative zero? Doesn't your second ~0 example actually represent ~-0?

--
Dan Henry
Reply to
Dan Henry

In 1's complement -0 is equal to +0.

--
 
 
 Click to see the full signature
Reply to
CBFalconer

Right, but I am wondering about the predictability of the underlying bit patterns.

Are you saying that in 1's complement the integer constant 0 could have the bit pattern for +0 (all 0's) *or* the bit pattern for -0 (all

1's) and that using the unary - operator on the integer constant 0 can yield either all 1's or all 0's -- that my memset(&object, 0, sizeof object) is equally likely to zero all bits as set all bits of the memory that object occupies?
--
Dan Henry
Reply to
Dan Henry

The sign/magnitude, 1's and 2's complement notation only apply to the _signed_ integer types.

For unsigned types (C99, 6.2.6.2p1):

"For unsigned integer types other than unsigned char, the bits of the object representation shall be divided into two groups: value bits and padding bits (there need not be any of the latter). If there are N value bits, each bit shall represent a different power of 2 between 1 and 2N=E2=88=921, so that objects of that type shall be capable of representing values from 0 to 2N =E2=88=92 1 using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified.44)"

So, ignoring the padding bits, the representation must be pure binary.

For the '~' operator it says (6.5.3.3p4)

"The result of the ~ operator is the bitwise complement of its (promoted) operand (that is, each bit in the result is set if and only if the corresponding bit in the converted operand is not set). The integer promotions are performed on the operand, and the result has the promoted type. If the promoted type is an unsigned type, the expression ~E is equivalent to the maximum value representable in that type minus E."

The C99 standard does not leave room for a system where ~0U equals

0x0000.
Reply to
Arlet

Almost. 0 is always represented as 0x0000. 0xffff would be a negative zero, and a literal never generates a negative zero (6.2.6.2p3: negative zeroes are only generated by bit-fiddling operators, or if you already have a negative zero). Thus, ~0 always gives an integer with representation 0xffff. But it's not guaranteed that you can ever store that representation anywhere.

When the signed integer with representation 0xffff is converted into an unsigned integer, its value is analyzed, not its representation, and the value is 0, thus 'unsigned i = ~0' might end up as 0x0000 stored.

But this can easily be fixed by writing 'unsigned i = ~0U', which is a good idea anyway when dealing with bits.

Stefan

Reply to
Stefan Reuther

Exactly.

--
 
 
 Click to see the full signature
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.