Set all bits to 1 in an array of raw bytes

[iesvs]

The word 'stack' isn't mentioned anywhere in the Standard. So there may well

be implementations without a stack or a stack pointer

Ok. But is there a way to define a variable without assign it to a
value (like I wanted to do). It offends me to make something which
breaks the natural symmetries.

 

[Joachim Schmitz]

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

en: indeterminate
de: unbestimmt
fr: indéfini, indéterminé
(assume from your email-address that your native language is frensh)

en: random
de: zufällig
fr: incidentaire

"radom, but within range of type" is what you assume in your program and
what your implementation seems to provide

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.

"Why questions" might be answered be the Rationale, a document that the
Standads body produced and made available for free.

 

[Joachim Schmitz]

news:[email protected]...

"radom, but within range of type" is what you assume in your program and

"random" of course...

 

[santosh]

Ok. But is there a way to define a variable without assign it to a
value (like I wanted to do).

Yes, just don't initialise it.

/* ... */
int myint;

/* ... */

 

[Joachim Schmitz]

Ok. But is there a way to define a variable without assign it to a
value (like I wanted to do). It offends me to make something which
breaks the natural symmetries.

if you define it outside of any function or as static, it'd be implicitly
initialized to 0 for you.

Bye, Jojo

 

[Ben Bacarisse]

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.

All I can find is a definition of indeterminate value:

3.17.2
indeterminate value
either an unspecified value or a trap representation

and a statement that the initial value of an uninitialised automatic
variable will be an "indeterminate value" (as we all know). The code
in question defines the variables as an unsigned char so trap
representations are out (I suspect that (e-mail address removed) is not aware of
this point) so putting these together we have that the value is
simply "unspecified".

Can you find C&V to go further? I can't see how the unspecified value
of an unsigned char can be outside the representable values for that
type. It is obviously possible for most types, but unsigned char has
only value bits.

I'd like *any* code involving indeterminate values to have undefined
behaviour, but I can't find the evidence in this case.

 

[Richard Heathfield]

Ben Bacarisse said:

The code
in question defines the variables as an unsigned char so trap
representations are out (I suspect that (e-mail address removed) is not aware of
this point) so putting these together we have that the value is
simply "unspecified".

Can you find C&V to go further?

Ah, I can - and it gives the lie to my earlier claim.

3.17.3
1 unspecified value
valid value of the relevant type where this International Standard imposes
no requirements on which value is chosen in any instance

I can't see how the unspecified value
of an unsigned char can be outside the representable values for that
type. It is obviously possible for most types, but unsigned char has
only value bits.

Yes, it was actually "most types" that I had in mind when I made the claim.
I had overlooked that we were dealing with unsigned chars.

I'd like *any* code involving indeterminate values to have undefined
behaviour, but I can't find the evidence in this case.

Oh, there's no question whatsoever that the code's behaviour is undefined.
Using an indeterminate value is sufficient. A sufficiently ornery compiler
could do all kinds of stuff at this point.

 

[Ben Bacarisse]

Ben Bacarisse said:



Ah, I can - and it gives the lie to my earlier claim.

3.17.3
1 unspecified value
valid value of the relevant type where this International Standard imposes
no requirements on which value is chosen in any instance

How does that help? The value must be of the relevant type so that is
not more than I was saying. All values of the type in question are
valid for the posted code.

Yes, it was actually "most types" that I had in mind when I made the claim.
I had overlooked that we were dealing with unsigned chars.


Oh, there's no question whatsoever that the code's behaviour is undefined.
Using an indeterminate value is sufficient.

This is what I hoped. Is there a statement that using an indeterminate
value is UB? I could not find it.

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

This is what I hoped. Is there a statement that using an indeterminate
value is UB? I could not find it.

There isn't one in C99.

 

[Joachim Schmitz]

This is what I hoped. Is there a statement that using an indeterminate
value is UB? I could not find it.

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).

 

[Ben Bacarisse]

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).

....but sadly not normative. If my reading of the other parts is
correct, it cannot trump that. Much as I'd like it to!

I am in the odd position of wanting to be wrong.

 

[Flash Gordon]

Joachim Schmitz wrote, On 28/09/07 19:48:

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).

Appendix J is not normative, so whilst it is useful explanatory text it
does not actually prove anything and could be wrong if there is no
normative text that supports it. In this case it could be a
generalisation that is not true for unsigned char which has no trap values.

Personally I think it would be better if the standard included the
statement you quoted in the normative text.

 

[pete]

There isn't one in C99.

That's right. It's undefined in C89.
Richard Heathfield is strongly C89 biased.

ISO/IEC 9899: 1990

3 Definitions and conventions

3.16 undefined behavior:
Behavior, upon use of a nonportable or erroneous program construct,
of erroneous data, or of indeterminately valued objects,
for which this International Standard imposes no requirements.

 

[Charlie Gordon]

# 6.5.3.4 The sizeof operator
...
# Semantics
...
# 3 When applied to an operand that has type char, unsigned char, or
# signed char, (or a qualified version thereof) the result is 1.

Are you perhaps related to our other regular Frenchman? Your
idiosyncratic view of the language seems a match for his.

That was uncalled for!

The iesvs troll is several orders of magnitude more obtuse and arrogant than
any other poster in the past 30 days. And he/she is probably not even
French at all.

 

[Wallace_78]

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

I'd like to apologize for what I'm doing here, in this group.

<French>
C'est un comportement indéfini : la valeur de b est _indéfinie_ (= la norme
ne dit rien concernant ce qui peut arriver dans un cas comme celui-là : le
comportement de l'implémentation est laissé libre à l'implémenteur), pas
/indéterminée/ (= valeur valide mais inconnue du développeur).
Par conséquent, une implémentation pourrait donc décider d'ouvrir le lecteur
CD (à supposer qu'il y en ait un) lors de l'exécution de votre bout de code.

Maintenant si vous jouez simplement au con ici, ce serait sympa d'arrêter.
Merci.
</>

Approximative translation in approximative english (please feel free to
correct me -- in both language and technical aspects) :

<>
This is an UB; the value of b is _undefined_ (ie the norm does not specify
anything concerning what may happen in such a situation : the implementor is
free to chose the behavior of his implementation), not /indeterminate/ (ie
value is valid but not known from the developer).
A conforming implementation may thus decide to open the CD reader (supposed
there is one on the platform) when executing your [[email protected]'s] code.
</>

 

[Ben Bacarisse]

Approximative translation in approximative english (please feel free to
correct me -- in both language and technical aspects) :

This is an UB; the value of b is _undefined_ (ie the norm does not specify
anything concerning what may happen in such a situation : the implementor is
free to chose the behavior of his implementation), not /indeterminate/ (ie
value is valid but not known from the developer).
A conforming implementation may thus decide to open the CD reader (supposed
there is one on the platform) when executing your [[email protected]'s] code.

I thought the result of the discussion what that, for unsigned char,
the code was well-defined. At least, I saw no persuasive argument
that is was undefined in the usual (C standard) sense.

Appendix J has a non-normative remark that suggests the intent was to
keep such code as undefined (I think it explicitly was in C90), but
the definitions of "indeterminate" and "unspecified" values suggest
the code was, oddly, OK.

Of course this is just language lawyering -- there can be no
reasonable purpose to use an indeterminate value in proper code, but
it might suggest, if there is no such catch-all already, that there
should be a "use of indeterminate values is always undefined" in the
document. Of course, it is just possible that the intent was to
permit such code, but that seems unlikely.