«

Keith Thompson said:

> jacob navia <> writes:
[...]
>> Users will discover this eventually, and an explanation is
>> necessary.
>
> (The extension being discussed is allowing casts as lvalues.)
>
> You're writing a tutorial about C, right?

I find my lack of faith disturbing.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Keith Thompson said:

> jacob navia <> writes:
>> Keith Thompson wrote:
>>> jacob navia <> writes:
> [...]
>>>> The object exists, since we can even take its address
>>>> within the called function.
>>> Yes, *within* the called function. The object (the parameter)
>>> doesn't exist outside the function; it's a local object with
>>> automatic storage duration.
>>
>> Thanks. You agree with me then, that the object exists, and exists
>> before the call, even if it is not accessible.
>
> I didn't say that, but I agree, more or less.

Then I misrepresented you in a parallel reply.

I have to say I think you're wrong, but I'm open to persuasion.

The expression under consideration is toupper((unsigned char)c), and the
question is whether it constitutes an lvalue; your contention appears
to be that this (unsigned char)c argument is guaranteed by the Standard
to be an lvalue, because its value is assigned to an object during the
function call.

I think you're wrong for two reasons, which I invite you to knock down:

1) it might not even /be/ a function call;
2) lexically, we can think of a function call like this:

(a) the function call expression - toupper((unsigned char)c)
(b) the function declarator - int toupper(int ch)
(c) the function body

The business of copying argument-expression values to parameter objects
and JSRing to the function can be thought of as the transition between
(a) and (b). Whether you think an object is created for storing the
result of the expression in (a) or in (b) depends on where, precisely,
you draw the line between them. Syntactically, the object is created,
*at the very earliest*, "in" the function declarator, and there's a
case for saying it's not created until you actually get "into" (c), the
function body itself.

<snip>

> An *argument* is not an object.

Hear, hear. So we are indeed in agreement after all, it seems.

> An argument is an expression
> appearing between the parentheses in a function call;

or a macro.

<snip>

> But C99 6.9.1p9 says:
>
> Each parameter has automatic storage duration. Its identifier is
> an lvalue, which is in effect declared at the head of the compound
> statement that constitutes the function body (and therefore cannot
> be redeclared in the function body except in an enclosed block).
>
> which implies that the parameter object isn't created until control
> passes the opening '{' of the function.

Indeed.

<snip>

> But in any case, the question from upthread is whether this statement:
>
> toupper((unsigned char)c);
>
> contains an lvalue. c is an lvalue, but (unsigned char)c is not, and
> statement does *not* contain an lvalue that refers to the parameter.

Right.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> CBFalconer said:
>> Richard Heathfield wrote:
>>> CBFalconer said:
>>>> Richard Heathfield wrote:
> <snip>
>>>>> For example, there is
>>>>> no lvalue in the (pointless but legal) statement:
>>>>>
>>>>> toupper((unsigned char)c);
>>>>
>>>> Yes there is, although it is well hidden. The functional parameter.
>>>
>>> No, it isn't well hidden. It isn't *there*. Not in that statement.
>>
>> We must be missing each others points. Where do you think the
>> conversion of c goes?
>
> It could easily go into a register, but that's beside the point.
> There's no object in the statement I presented.
>
>> All the elements of the library have to be available as functions,
>> and macros (if provided) can only mimic a function call.
>
> Yes, but the statement I presented is not a function definition.
> It is merely a function call.

Which, in turn, requires a location to hold a parameter. Hidden.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net



--
Posted via a free Usenet account from http://www.teranews.com

Richard Heathfield wrote:
>
.... snip ...
>
> Two problems with this - firstly, you're trying to nudge the discussion
> further and further into the called function in an attempt to shore up
> your case, but we're discussing the cast-expression, not the execution
> details of the called function; and secondly, there isn't necessarily a
> function call at all! The expression, remember, was toupper((unsigned
> char)c), and the implementation is perfectly at liberty to convert this
> into something like:
> (((unsigned char)c) == EOF) ? EOF : __toupper[((unsigned char)c)]
>
> where __toupper is an array in read-only memory.

No it can't. That expression evaluates c twice, and is forbidden
for macro expansions of the std. library (apart from getc).

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net



--
Posted via a free Usenet account from http://www.teranews.com

Richard Heathfield wrote:
> Keith Thompson said:
>
> <snip>
>
>> An *argument* is not an object.
>
> Hear, hear. So we are indeed in agreement after all, it seems.

Nonsense. An argument is always an expression, converted into an
object, which is not accessible before entry to the sub-routine.
At that point it can be treated as any other local object.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net


--
Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:
> Richard Heathfield wrote:
>> Keith Thompson said:
>>
>> <snip>
>>
>>> An *argument* is not an object.
>> Hear, hear. So we are indeed in agreement after all, it seems.
>
> Nonsense. An argument is always an expression, converted into an
> object, which is not accessible before entry to the sub-routine.
> At that point it can be treated as any other local object.
>

That is exactly what I said.

jacob

P.S. But even if i would say
two plus two is four
I guess Mr heathfield would say

NO. It isn't.

CBFalconer said:

> Richard Heathfield wrote:
>>
> ... snip ...
>>
>> Two problems with this - firstly, you're trying to nudge the
>> discussion further and further into the called function in an attempt
>> to shore up your case, but we're discussing the cast-expression, not
>> the execution details of the called function; and secondly, there
>> isn't necessarily a function call at all! The expression, remember,
>> was toupper((unsigned char)c), and the implementation is perfectly at
>> liberty to convert this into something like:
>> (((unsigned char)c) == EOF) ? EOF : __toupper[((unsigned char)c)]
>>
>> where __toupper is an array in read-only memory.
>
> No it can't. That expression evaluates c twice, and is forbidden
> for macro expansions of the std. library (apart from getc).

Oops.

How about this:

((__zog = ((unsigned char)c)) == EOF) ? EOF :__toupper[__zog]

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

CBFalconer said:

> Richard Heathfield wrote:
>> Keith Thompson said:
>>
>> <snip>
>>
>>> An *argument* is not an object.
>>
>> Hear, hear. So we are indeed in agreement after all, it seems.
>
> Nonsense.

I disagree.

> An argument is always an expression,

Right.

> converted into an object,

Not quite. The value of the expression is *assigned* to an object.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia said:

<snip>

> P.S. But even if i would say
> two plus two is four
> I guess Mr heathfield would say
>
> NO. It isn't.

Well, it needn't be; for example, in the ring containing only the
numbers 0, 1, 2, 3, 2 + 2 would be 0, not 4 - of course, that's merely
a nit-pick.

But in fact I'm perfectly happy to agree with you when you're right.
It's only when you're wrong that I disagree with you. That is why I
disagree with you so often.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On Jun 26, 6:15 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Oops.
>
> How about this:
>
> ((__zog = ((unsigned char)c)) == EOF) ? EOF :__toupper[__zog]

But...

Weren't you trying to show that toupper((unsigned char)c) doesn't
necessarily contain an lvalue with the value of (unsigned char)c ?

--
Mark