Re: segfault w/ block, but not file scope
- From: Lew Pitcher <lpitcher@xxxxxxxxxxxx>
- Date: Sun, 08 Jan 2006 00:30:11 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joseph Dionne wrote:
> Keith Thompson wrote:
>
>> Joseph Dionne <jdionne@xxxxxxxxxxx> writes:
>> [...]
>>
>>> No way! '&' is a bit wise logical AND, to get the contents of a
>>> pointer, one codes it as "&pointer" not "& pointer" which will
>>> generate an error.
Fortunately, the C language has rules that permit implementations to
distinguish between a "binary bitwise logical and" operator and a "unary
prefix address of" operator, even if they both share the same translation token.
Are you telling me that
{
int a = 7, b = 4, *c;
c = & a;
}
will result in a syntax error? I think not.
>> I'm beginning to suspect that you may be a deliberate troll.
[snip]
>> The unary "&" operator doesn't yield the contents of a pointer; it
>> yields the address of an object.
[snip]
>
> It is just as amusing as you assertion, backed by no well known
> authority of the c language specification, that c does not support pass
> by reference.
- From the C 9989-1999 proposed standard (and, IIRC, from previous C standards,
all the way back to K&R C and forward to the accepted C'99 standard)
6.5.2.2 Function Calls
4 An argument may be an expression of any object type. In preparing for a
call to the function, the arguments are evaluated, and each parameter is
assigned the value of the corresponding argument.
Sounds like the standard says "pass by value" to me. And it doesn't say "pass
by reference" anywhere in it.
Perhaps you've become fooled by the mechanics of pointer variables. Passing
pointers to functions can /look/ like "pass by reference" even though it is
actually "pass by value". Consider the following code fragments
void foo(int *a)
{
/* body of function foo */
*a = 8;
}
void bar(void)
{
int q = 6;
foo(&q);
}
In the above functions, you might think that "pass by reference" is being
used, but it is not.
In the context of the function call to foo() ( "foo(&q);" )
q is an object of type int.
&q is another object (a temporary one crafted by the language to serve as a
vehicle to pass data to a function) of type "pointer to int"
q has a value of 6
&q has a value of a pointer to q
Function foo() will receive the /value/ of the temporary object &q. It does
not receive a /reference/ to q (or even to the temporary &q). It's as if that
original function had been coded as
void bar(void)
{
int q = 6;
int *pq = &q;
foo(pq); /* still pass by value, just value of pq */
}
> Your continued reference to 'object' during replies proves my assertions
> -- recent OOP development (decades ago implemented recent, I mean)
Well, Keith is using the word "object" in the same manner (and apparently with
the same meaning) as the C standard (and it's predecessor documents) does.
- From the C 9989-1999 proposed standard document section 3 ("Terms, definitions
and Symbols"):
3.14
object
region of data storage in the execution environment, the contents of which
can represent values
C 9989-1999 goes on using the word "object" throughout it's text, in exactly
the context that Keith has used it. I'm afraid that you don't have any choice
but to accept this terminology, recent OOP usage or not.
> have
> obfuscated the meaning of "pass by reference". I suspect this is due
> mostly to the declining software knowledge, and skills, that has again
> raised the acclaim and praise for "garbage collection" languages.
>
> Show me any authority that shares you "opinion" that c does not "pass by
> reference".
I think that the C standards should be sufficient authority to confirm Keith's
"opinion".
- --
Lew Pitcher
Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
iD8DBQFDwKNjagVFX4UWr64RAvDrAJ9JRNN/WaXaq0J4O4egJiuRwCtNiQCeN/y5
ou4vGFXt3wBzmmUDCwCz/+I=
=p6kP
-----END PGP SIGNATURE-----
.
- References:
- segfault w/ block, but not file scope
- From: Dieter
- Re: segfault w/ block, but not file scope
- From: Dieter
- Re: segfault w/ block, but not file scope
- From: Jack Klein
- Re: segfault w/ block, but not file scope
- From: Dieter
- Re: segfault w/ block, but not file scope
- From: M.B
- Re: segfault w/ block, but not file scope
- From: Richard Heathfield
- Re: segfault w/ block, but not file scope
- From: M.B
- Re: segfault w/ block, but not file scope
- From: Richard Heathfield
- Re: segfault w/ block, but not file scope
- From: Keith Thompson
- Re: segfault w/ block, but not file scope
- From: Richard Heathfield
- Re: segfault w/ block, but not file scope
- From: Keith Thompson
- Re: segfault w/ block, but not file scope
- From: Richard Heathfield
- Re: segfault w/ block, but not file scope
- From: Keith Thompson
- Re: segfault w/ block, but not file scope
- From: Joseph Dionne
- Re: segfault w/ block, but not file scope
- From: Keith Thompson
- Re: segfault w/ block, but not file scope
- From: Joseph Dionne
- Re: segfault w/ block, but not file scope
- From: Keith Thompson
- Re: segfault w/ block, but not file scope
- From: Joseph Dionne
- segfault w/ block, but not file scope
- Prev by Date: Re: segfault w/ block, but not file scope
- Next by Date: Re: segfault w/ block, but not file scope
- Previous by thread: Re: segfault w/ block, but not file scope
- Next by thread: Re: segfault w/ block, but not file scope
- Index(es):
Relevant Pages
|