Set all bits to 1 in an array of raw bytes

[iesvs]

See page 490 of ISO/IEC 9899:1999 for a summary of why you are wrong. Then

chase the references.

I respect standard and understand them. But if you want an advice,
open a mathematical book, about the concept of convergence of
function. And think about it.
I help you :
http://en.wikipedia.org/wiki/Convergence

Even with the undefined behavior it works. What do you want me to say.
Undefined behavior doesn't mean banned. It's just mean you have to
know what you're doing and in this case I know.
Do you want a proof ?
Do you want a code which test all the values for b and prove it to
you ?

Did you try this function with all different initial possible values
for b ? If you did it, you would have seen that it works each time,
sorry.

Bai-Chi

 

[Richard Heathfield]

(e-mail address removed) said:

I respect standard and understand them. But if you want an advice,

....if I want advice, I'll seek it from someone who is demonstrably
competent - which lets you out nicely.

Even with the undefined behavior it works.

Whether it works is undefined. You fail to understand the nature of
undefined behaviour.

<snip>

 

[Joachim Schmitz]

(e-mail address removed) said:


See page 490 of ISO/IEC 9899:1999 for a summary of why you are wrong. Then
chase the references.

You meant the following, didn't you?

J.2 Undefined behavoir
....
- The value of an object with automatic storage duration is used while it is
indeterminate (6.2.4, 6.7.8, 6.8).



Bye, Jojo

 

[iesvs]

...if I want advice, I'll seek it from someone who is demonstrably

competent - which lets you out nicely.

I say you, I got. But go find a guy who will explain to you that I'm
right.

Whether it works is undefined. You fail to understand the nature of
undefined behaviour.

I understand it.

I gonna to help yourself.
Ok I will consider sizeof (char == 1) but I think that for you it's
not a problem.
The problem is :
a = 2 * b + 1
undefined behavior because b could have 256 values {0, 1, ..., 254,
255}
a could be after one step :
{1, 3, 5, ..., 253, 255} 128 possible values
after two:
{3, 7, 11, ..., 251, 255} 64 possible values
after three:
{7, 15, 23, ..., 247, 255} 32 possible values
after for:
{15, 31, ..., 239, 255} 16 possible values
five:
{31, 63, ..., 223, 255} 8 possible values
six:
{63, 127, 191, 255} 4 possible values
seven:
{127, 255} 2 possible values
eight:
{255} 1 possible values

Oh, it's magic the undefined behavior becomes a defined behavior.
Magic magic.
Do you understand or you refuse.

Bai-Chi

 

[Joachim Schmitz]

The problem is :
a = 2 * b + 1
undefined behavior because b could have 256 values {0, 1, ..., 254,
255}

No, b's value is indeterminate, it does not neccessarily contain any of the
values you stated.
The implementation might not have generate any code for b up until the point
where a value is assigned to it the first time, so you may be reading from
nowhere land if you read from it before it has been initialized. The
Standard intentionally left this behavoir undefined to give some freedom to
the implementation.

That it works for you is just one possible consequence of UB

Bye, Jojo

 

[Mark Bluemel]

I don't think so. I think the section on "Representation of
types" in the standard will cover this.

Mostly. With "Unary arithmetic operators" and the section named
above we have: 2's complement ~0 is -1, 1's complement ~0 is 0
(may be negative zero) and sign/magnitude ~0 is INT_MIN.
Additionally taking "Signed and unsigned integers [conversions]"
into account (unsigned char)~0 will be UCHAR_MAX, 0 (unless ~0
is a trap representation) or 1, respectively.

So the result truely depends on "Representation of types" which
actually is implementation-defined.

Thanks for clarifying. I've been taking notes, but don't expect to pass
the written exam...

 

[iesvs]

No, b's value is indeterminate, it does not neccessarily contain any of the

values you stated.

The space is allocated in the stack. And b correspond to this space. A
char couldn't be anything else than a char. indeterminate means that
we can't assume the value is always 0 (by example).

 

[Joachim Schmitz]

The space is allocated in the stack. And b correspond to this space. A
char couldn't be anything else than a char. indeterminate means that
we can't assume the value is always 0 (by example).

no, indeterminate means indeterminate, not random but within range of the
type

Wordings are very important, esp. in standards and law texts

 

[Richard Heathfield]

(e-mail address removed) said:

The space is allocated in the stack.

The C Standard does not require this. Nor does it require the existence of
a stack.

And b correspond to this space. A
char couldn't be anything else than a char. indeterminate means that
we can't assume the value is always 0 (by example).

3.17.2
1 indeterminate value
either an unspecified value or a trap representation

Using such a value invokes undefined behaviour - i.e. behaviour upon which
the Standard imposes no constraints whatsoever.

 

[Richard Heathfield]

Joachim Schmitz said:

no, indeterminate means indeterminate, not random but within range of the
type

The Standard does not in fact require that an indeterminate value must be
within the range of values appropriate to its type.

Wordings are very important, esp. in standards and law texts

Indeed.

 

[Mark Bluemel]

(e-mail address removed) said:


The C Standard does not require this. Nor does it require the existence of
a stack.


3.17.2
1 indeterminate value
either an unspecified value or a trap representation

Using such a value invokes undefined behaviour - i.e. behaviour upon which
the Standard imposes no constraints whatsoever.

I suspect that you'd do better talking to the cat...

 

[iesvs]

not random but within range of the type
Sorry, this I don't understand, I'm not so good at English.
But do you mean that the stack pointer is not moved to allocate a
space for a char ? In this case I'll understand that my code is
dangerous.

And for the one who says that the *2 is not well behaved, yes, but it
was not the argument you used and I made hypothesis about that, if
someone had say me my hypothesis was false I would have abdicated. But
criticize a valid reasoning, I can't accept.

 

[Joachim Schmitz]

Joachim Schmitz said:


The Standard does not in fact require that an indeterminate value must be
within the range of values appropriate to its type.

That's what I said. At least what I meant... "random but within range of the
type" on one side and "indeterminate" on the other.

Bye, Jojo

 

[Fred]

I understand it.

You don't understand it. You don't have the slightest clue what you're
talking about.

I gonna to help yourself.
Ok I will consider sizeof (char == 1) but I think that for you it's
not a problem.
The problem is :
a = 2 * b + 1
undefined behavior because b could have 256 values {0, 1, ..., 254,
255}

No, the value of b is unspecified.

Undefined behavior is undefined. The compiler could note that you're
reading the value of b while it's indeterminate and replace the line
a=2*b+1; with system("rm -rf /");

 

[Joachim Schmitz]

Sorry, this I don't understand, I'm not so good at English.
But do you mean that the stack pointer is not moved to allocate a
space for a char ? In this case I'll understand that my code is
dangerous.

The word 'stack' isn't mentioned anywhere in the Standard. So there may well
be implementations without a stack or a stack pointer
Or the implementation might elect to create that char on the stack in the
very moment it gets a value assigned.

Bye, Jojo

 

[Richard Heathfield]

Mark Bluemel said:

I suspect that you'd do better talking to the cat...

All this stuff is so easy that I'm actually letting my cat type it. She has
more patience than I do.

 

[Richard Heathfield]

Joachim Schmitz said:

That's what I said. At least what I meant... "random but within range of
the type" on one side and "indeterminate" on the other.

Oh, I see what you mean now. Sorry. (If the quotation marks had been
present in the original, I'd have sussed it.)

The trouble with writing is that its meaning is obvious to the *writer*,
and so it is natural to assume that it is also obvious to the reader. I
suspect we all suffer from this to some extent, which is why maintenance
people fill up swear-boxes so quickly.

 

[iesvs]

That's what I said. At least what I meant... "random but within range of the

type" on one side and "indeterminate" on the other.

It's too subtle English for me. If you could talk like I was a dumb I
would better understand.


But is the space allocated in the stack and b refers to this space ?


And another question, why are there architecture where the 2's
complement is not used ? We could multiply, add, subtract (not divide
we're not on a good structure) without thinking because it's mean
count modulo (% if it's not the word) 256.

 

[Richard]

In the real world however, while discussing C in real projects ....

I suspect that you'd do better talking to the cat...

*blink*

 

[Mark Bluemel]

Mark Bluemel said:

[regarding (e-mail address removed)]

All this stuff is so easy that I'm actually letting my cat type it. She has
more patience than I do.

However my previous posting on the wise Malagasy saying seems to hold in
this case...