Re: Null terminated strings: bad or good?

"Wojtek Lerch" <Wojtek_L@xxxxxxxx> writes:

"Tim Rentsch" <txr@xxxxxxxxxxxxxxxxxxx> wrote in message
news:kfnocy84dy9.fsf@xxxxxxxxxxxxxxxxxxxxxx
So based on the above I think the Standard uses the word "type"
to mean "how are the bits of an object (or returned by a
function) interpreted to associate an abstract value" (the text
uses the word "meaning" rather than "abstract value"). Seen in
this way, the range of a type is not an inherent property of the
type but a derived property of object representations for
variables declared to be of that type. There's no inconsistency
if assign a type T to a value V outside the range of values
that can be represented by an object of type T; it's only when
we go to store V in an object of type T that it must be in
the range of representable values.

So you're basically saying that there can be values whose type is size_t
that can't be represented in their type, and that SIZE_MAX is the maximum
value representable as a size_t but not necessarily the greatest possible
value that an expression with the type size_t (such as a sizeof expression)
can produce? That definitely sounds like a very unorthodox interpretation
to me.

It may be unorthodox, but it's consistent with how the Standard
talks about types, and how expressions are evaluated, and it fits
in with what the Rationale document says about what sizeof does
"if the size is too large to represent as a size_t". Personally,
I find it more aesthetically appealing than some of the other
suggestions; the metric I use for evaluation, however, is not
how aesthetically appealing it is, but how consistent is it, and
how well does it fit in, with everything else said in the
official ISO documents? Judged under that metric, I think this
interpretation does fairly well.


Furthermore, if you read through the sections about conversions,
I think you'll find that all this works for values of the
sizeof operator that have type size_t but are outside the
range of representable values for size_t. In particular,

int x[1024][1024];
int x_index_limit = sizeof x / sizeof x[0];

gives the right value [*] for x_index_limit (that is, 1024) even if
the condition sizeof x > (unsigned long long) SIZE_MAX is true.

As a sanity check we should look at what happens when we assign
one size_t value to another, as for example

size_t x_size = sizeof x;

under the assumption sizeof x > (unsigned long long) SIZE_MAX .
Here also there is no problem caused by the overly large value,
because assignement converts the value of the right operand to
the type of the left operand, which ensures that the value stored
will be in the range of values representable in a size_t.

No, a conversion from size_t to size_t is not supposed to change the value
(6.3#2).

The single sentence in 6.3p2 is written as being absolutely true,
but it is not true absolutely. For example,

double x, y = something(), z = something_else();
x = y + z;

The assignment converts the right hand side value (a double) to
the type of x (also double). The conversion that happens on this
assignment can, and frequently does, change both the value and
the representation of the operand value y + z.

We can speculate that 6.3p2 was written to say something about
conversion between types that are /compatible/ but not
/identical/ -- a kind of reassurance that conversion between
distinct-but-still-compatible types is a no-op. Whether that's
true or not, the conversion between an overly-large sizeof value
and a size_t is similar enough to what happens with floating
point operands -- that is, even though the type is the same there
is extra range or precision -- so that having an additional
special case shouldn't be too much cause for concern.
.

Relevant Pages

  • Re: Null terminated strings: bad or good?
    ... that can't be represented in their type, and that SIZE_MAX is the maximum value representable as a size_t but not necessarily the greatest possible value that an expression with the type size_t (such as a sizeof expression) can produce? ... That definitely sounds like a very unorthodox interpretation to me. ... the type of the left operand, which ensures that the value stored ...
    (comp.std.c)
  • Re: [9fans] fun and scary evil C code
    ... of floats and doubles or the exact conversion of constant ... I'm fairly sure they somehow mandate IEEE 754 properties, ... but do they actually say that floats and doubles have to be stored ... differing representations. ...
    (comp.os.plan9)
  • Re: Null terminated strings: bad or good?
    ... point out any statement in the Standard that establishes either ... The value of sizeof has the type size_t, and therefore it must be within the ... Furthermore, if you read through the sections about conversions, ...
    (comp.std.c)
  • Re: conversions between fixed-point types
    ... The conversion to FpB is governed by G.2.3, so both -1.2 and -1.6 are in the close result set. ... when you have some code that is executed cyclically every 100ms and delivers sensor sample values. ... At some point during the calculation, however, you will have to make the conversion from the world of types with "physical" representations, to the world of binary representations. ...
    (comp.lang.ada)
  • Re: type writers and tooth aches II
    ... > But you are forgetting that that whole interpretation is a result of ... if my representations get out of sync with the world, ... > nutrition, a body to interface them with the environment, sensory input ... It's justified by the fact that that the brain use representations, ...
    (comp.ai.philosophy)
Loading