Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > A question on string literals

Reply
Thread Tools

A question on string literals

 
 
Tim Rentsch
Guest
Posts: n/a
 
      08-19-2005
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
> > Keith Thompson <(E-Mail Removed)> writes:
> >
> >> pete <(E-Mail Removed)> writes:
> >> > Tim Rentsch wrote:
> >> >>
> >> >> Keith Thompson <(E-Mail Removed)> writes:
> >> >
> >> >> > An array isn't (necessarily) a non-modifiable lvalue.
> >> >>
> >> >> An array is never a modifiable lvalue; 6.3.2.1 p1.
> >> >
> >> > "A modifiable lvalue is an lvalue that does not have array type, "
> >>
> >> Right. The comma is critical; there are more criteria. (I mention
> >> that because I mis-read it the first time.)
> >>
> >> (I added the "(necessarily)" because I was too lazy to think it
> >> through and/or look it up. It wasn't meant to imply that an array can
> >> sometimes be a modifiable lvalue, though I see that it could be read
> >> that way.)

> >
> > Ah, now I see what you meant: an array wouldn't *have* to
> > be a non-modifiable lvalue. I believe that statement is
> > correct; the standard could have been written so array
> > expressions were modifiable lvalues, and nothing would
> > change, because in every place where it might be relevant
> > the array expression would be converted to a pointer, and so
> > would be illegal anyway. Probably 6.3.2.1 p1 excludes array
> > expressions from being modifiable lvalues so as to make it
> > absolutely clear that arrays can't be used with =, ++, etc.

>
> I'm glad you were able to read into what I wrote something cleverer
> than what I intended. In fact, I was just being lazy. If I had spent
> a minute or two doing more research, I could have dropped the
> "(necessarily)"; I didn't bother because it didn't seem relevant to my
> point. I should have realized that irrelevance doesn't prevent long
> threads. }


I usually look for the "smartest" reading in what people
write. It's often right, and it rarely hurts to give
someone the benefit of any doubt. Also I figure looking
for the best possible interpretation benefits me, since
when I do I sometimes find significant points that I
wouldn't otherwise.


> Yes, I suppose the "does not have array type" phrase in 6.3.2.1p1 is,
> strictly speaking, redundant, but it's a *good* redundancy. Without
> it, if arr is an array object, then the name "arr" in "sizeof arr" or
> "&arr" would be a modifiable lvalue, but it wouldn't matter because
> neither operator modifies its argument. But I think the wording is
> cleaner as it is.


Agreed.
 
Reply With Quote
 
 
 
 
Chris Torek
Guest
Posts: n/a
 
      08-20-2005
>> Chris Torek wrote:
>>> &foo - object context
>>> sizeof foo - object (or maybe even "sizeof") context

[snippage]
>>> and so on.


>Joe Wright <(E-Mail Removed)> writes:
>> I know you Chris and I love you like a brother but given..
>> int foo = 2, bar = 3;
>>
>> &foo - is the address of foo, a 'value' of type (int*)
>> sizeof foo - is a value (4 at my house) of type (size_t)
>> ++foo - is a value (now 3) of type (int)
>>
>> None of these have 'object' context as I see it. What are you trying
>> to tell us here?


In article <(E-Mail Removed)>
Keith Thompson <(E-Mail Removed)> wrote:
>In "&foo", he's talking about the context in which the name "foo"
>appears, not the entire expression. The argument to the unary "&"
>operator must be an lvalue, so foo is in an "object context". Similarly,
>the argument of unary "++" must be an lvalue.


Keith is right about this.

>He's mistaken about sizeof, which doesn't require an lvalue.


This is true, and is why I said "or maybe even `sizeof context'".
Sizeof is even more exceptional than unary-&.

Finally, I would like to note that -- while it was never added to
C99 -- there have been various proposals, over the years, to
implement array assignment in C. I suspect that C1X or C2X (if
these ever come about) may eventually do so -- and if so, I believe
the "most natural" way to handle array assignment is to add a rule
that says, in:

a = b

if "a" has type "array N of T", b is converted to a value of type
"pointer to T" (and if it does not match a diagnostic is required);
then the code acts much like a call of the form:

memcpy(&a[0], b, sizeof a)

except that the type of the result is "pointer to T" (rather than
"pointer to void").

If this *were* added to C, the left side of a simple asignment
operator would join the ranks of the "exceptions" for the
array-to-pointer conversion rule.

Of course, there are also "obvious" and "natural" (to me anyway)
interpretations for:

arr += arithmetic_type;
arr -= arithmetic_type;
arr++; /* same as arr += 1 */
arr--; /* same as arr -= 1 */
/* and so on for all arithmetic and logical operators */

which involve replicated arithmetic applying the right-hand-side
value (or implied 1, for ++ and --) to each element of the array,
with the value of the expression as a whole again being "pointer
to first element of array". (Some might object that this renders
identical values for arr++ and ++arr, to which I say: "so what?" )

All of these interpretations arise from one single central idea:
naming an array always just names the entire array, but the "value"
of an array (when a value is needed) is computed by finding a
pointer to its first element. If a value is *not* needed, the
array still names the entire array.

Again, this is not quite what the actual C standards (C89 and C99
both) say, but it delivers the same result, in what I think is a
simpler, yet ultimately more powerful, way.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      08-26-2005
Chris Torek <(E-Mail Removed)> writes:

>[snip]
>
> Finally, I would like to note that -- while it was never added to
> C99 -- there have been various proposals, over the years, to
> implement array assignment in C. I suspect that C1X or C2X (if
> these ever come about) may eventually do so -- and if so, I believe
> the "most natural" way to handle array assignment is to add a rule
> that says, in:
>
> a = b
>
> if "a" has type "array N of T", b is converted to a value of type
> "pointer to T" (and if it does not match a diagnostic is required);
> then the code acts much like a call of the form:
>
> memcpy(&a[0], b, sizeof a)
>
> except that the type of the result is "pointer to T" (rather than
> "pointer to void").


One would hope [0] that for an array assignment 'a = b' both
'a' and 'b' would have to be array expressions (and perhaps
even of identical numbers of elements). The chance of
memory being illegally accessed if b were allowed to be just
a pointer (which is implied, although not actually stated,
in Chris's comments), seems like too big a risk to allow
without needing an overt effort from the programmer. If a
pointer value were present for the right hand side, it could
always be cast to a suitable array type.

Also, to be consistent, the result of the array assignment
expression would still be of array type, so

a = b = c;

could be done.


[0] In the sense that at least one would hope because I
would, and I also would hope others would also.


> If this *were* added to C, the left side of a simple asignment
> operator would join the ranks of the "exceptions" for the
> array-to-pointer conversion rule.


Likewise the right hand side of an assignment expression where
the left hand side has array type.


> Of course, there are also "obvious" and "natural" (to me anyway)
> interpretations for:
>
> arr += arithmetic_type;
> arr -= arithmetic_type;
> arr++; /* same as arr += 1 */
> arr--; /* same as arr -= 1 */
> /* and so on for all arithmetic and logical operators */
>
> which involve replicated arithmetic applying the right-hand-side
> value (or implied 1, for ++ and --) to each element of the array,
> with the value of the expression as a whole again being "pointer
> to first element of array". (Some might object that this renders
> identical values for arr++ and ++arr, to which I say: "so what?" )


If extensions like these were going to be made, it seems
like it would be important to preserve the semantic
properties that C developers are used to for scalar
variables. In particular, for

a = b++;
a = ++b;

with both sides being arrays, it would be strange if the
two statements above had identical behavior. Certainly
it violates "The Law of Least Astonishment".

I don't know how useful (or non-useful) these kinds of
operators would be for array types, but certainly it seems
like there's a strong possibility of semantic confusion.
(Also programmer confusion, but who cares about that?


> All of these interpretations arise from one single central idea:
> naming an array always just names the entire array, but the "value"
> of an array (when a value is needed) is computed by finding a
> pointer to its first element. If a value is *not* needed, the
> array still names the entire array.


Perhaps this needs to be said differently. An expression
of array type remains an array when the context where it's
used needs an array; otherwise the array-type expression
is converted into a pointer to the array's first element,
as usual.

To be the most useful, it seems like array "assignment"
would also need to extend to passing of function parameters
and function results. There might be some difficulties
here. That's not to say that they couldn't be worked out,
but it's easy to imagine that there would be some unexpected
consequences.


> Again, this is not quite what the actual C standards (C89 and C99
> both) say, but it delivers the same result, in what I think is a
> simpler, yet ultimately more powerful, way.


I believe C would benefit from having arrays be more
completely integrated into the language, including at least
assignment and parameter/result passing. However, I suspect
the effort required for working out all the details for that
is more than many C experts might guess.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Java: byte literals and short literals John Goche Java 8 01-17-2006 11:12 PM
Generic class literals - e.g,, Class<Map<String, Integer>>.class Purush Java 4 04-13-2005 08:40 PM
character literals and string Pete Elmgreen Java 3 11-24-2004 04:42 PM
string literals question copx C Programming 9 09-06-2004 09:44 PM
String literals in Java Harri Pesonen Java 59 06-02-2004 08:00 PM



Advertisments