segfault w/ block, but not file scope

[aegis]

I disagree.


The language itself supports absolutely squat in regards to another
concept called "linked list", or "binary tree", or any number of other
things, which means absolutely squat to people who use those concepts
anyway in C regardless.

What a terrible comparison. The actual passing mechanism
supported by C is defined by the standard. Because
it is a mechanism of the language. Concepts such as
'linked list' and 'binary tree' are implemented with the
language. Not /into/ the language. So you compare to a
concept not associated with making up the actual language.
Call by value or pass by value is clearly outlined in
section 3.3.2.2 of c89. Which section describes this
so called concept 'pass by reference' or 'call by reference'?
I suspect there is no section as there is no mechanism of
such implemented into the language.

 

[Richard Tobin]

Perhaps it would be clearer to say that you are "passing a reference"
rather than "passing by reference"?

[/QUOTE]

No, because too many readers will assume "reference" refers to a
certain C++ language feature that C lacks.

Not being a C++ user, I was unaware of that. But I think it will be
hard to find a term that won't be misunderstood by some group, and I
am disinclined to allow C++ to distort our terminology so much.

-- Richard

 

[Default User]

Does K&R really say that arguments are passed by placing their values
on "the stack"? I'd be a bit surprised by that, since the C standard
doesn't talk about a stack, and a number of real-world implementations
pass most arguments in registers.

The only references to a "stack" I find in K&R2 is their own stack
routines they devised for doing some calculator-type stuff.



Brian

 

[Mark McIntyre]

Not being a C++ user, I was unaware of that. But I think it will be
hard to find a term that won't be misunderstood by some group, and I
am disinclined to allow C++ to distort our terminology so much.

This is probably a case where we should avoid the confusion.
Look at the mess that "const" and sizeof('Q') creates...
Mark McIntyre

 

[Joseph Dionne]

Keith Thompson wrote:





The only references to a "stack" I find in K&R2 is their own stack
routines they devised for doing some calculator-type stuff.



Brian

It astounds me to read some the post here, most being "off topic" or "don't do
that" for people seeking solutions to problems the responders have most likely
implemented.

It also astounds me to realize how many c programmers, a low level language,
have little to no understanding of how the c compiler works, some even
claiming the OS "jumps to main" which is completely false. It is apparent
many posters have little understanding of the structure of an executable
object created by the compiler, or how executable object loaders function.

I guess "in the old days" when we micro programmers has to write our own
program overlay loaders to work in the 65KB of available memory are not only
gone forever, but completely forgotten.

The first time I saw my first simple Windoze "hello world" MS C program create
and executable of 640KB, I almost freaked.

With all due respect people, we are coding to hardware architectures -- CPUs,
PIAs, memory address controllers, etc -- and using c for it tight code
generation for speed. I doubt any new c programmers even attempt to learn
assembler for the processor they work on most, or use their c compiler to emit
the assembler code and see the correlations between the c code to what is
being generated.

I never thought micro programmers would become as arrogant as mainframe
programmers use to be towards we who jumped to micros thirty years ago.

Sorry if I offended anyone, it was not my intention. Just need to vent, I guess.

 

[Default User]

Joseph Dionne wrote:

It astounds me to read some the post here, most being "off topic" or
"don't do that" for people seeking solutions to problems the
responders have most likely implemented.

More blither blather from you. And, in my mind, more than enough.


*plonk*





Brian

 

[Keith Thompson]

It astounds me to read some the post here, most being "off topic" or
"don't do that" for people seeking solutions to problems the
responders have most likely implemented.

This newsgroup discusses the C programming language as defined by the
ISO standard(s) (C99 and C90); older references such as K&R1 are also
topical for historical discussions. If you want to discuss something
that's specific to some system, you can do so in a newsgroup that
discusses that system.

I understand that the name "comp.lang.c" might lead you to think that
we discuss anything and everything having to do with C programming.
We don't. Now you know.

It also astounds me to realize how many c programmers, a low level
language, have little to no understanding of how the c compiler works,
some even claiming the OS "jumps to main" which is completely false.
It is apparent many posters have little understanding of the structure
of an executable object created by the compiler, or how executable
object loaders function.

There is no such thing as "the C compiler". There are a plethora of C
compilers, and they don't all work the same way. The only thing they
all have in common is that they all (to the extent that they're
correct) implement the C programming language. The core of that
language is defined by the ISO standard(s). (I'm being vague about
C90 vs. C99 because C99 is the current "official" standard, but C90 is
still more widely implemented.)

[snip]

With all due respect people, we are coding to hardware architectures
-- CPUs, PIAs, memory address controllers, etc -- and using c for it
tight code generation for speed. I doubt any new c programmers even
attempt to learn assembler for the processor they work on most, or use
their c compiler to emit the assembler code and see the correlations
between the c code to what is being generated.

Most of us are coding programs that are intended to perform some
particular task. Very often we can do so in standard C, without
concern for what the underlying hardware look like; if so, the code is
likely to be portable to different systems, which is an extremely
useful attribute. Occasionally, we might need to delve into
system-specific features; such things are best discussed in
system-specific newsgroups.

And I couldn't help noticing that you never actually answered my
question. I'll ask it again: Does K&R really say that arguments are
passed by placing their values on "the stack"? I've just checked my
copies of K&R1 and K&R2, and the answer appears to be no (I see no
mention of a "stack" in the section on functions and argument passing,
and there's no "stack" entry in either book's index). But, as they
say, you can't grep dead trees, and I could have missed something.

In the short time you've been here, you've posted a number of things
that are simply incorrect. (The most blatant was your statement about
unary vs. binary "&".) We all make mistakes now and then, but
refusing to acknowledge them is an efficient way to destroy your own
credibility.

 

[Mark McIntyre]

It also astounds me to realize how many c programmers, a low level language,
have little to no understanding of how the c compiler works,

You can't infer this from posts to CLC, since the topic here is hte C
language, not any specific compiler and how it works

With all due respect people, we are coding to hardware architectures

sure, but in CLC we're discussing C, nto architectures, cpus etc.,

Sorry if I offended anyone, it was not my intention. Just need to vent, I guess.

Also need to stay ontopic.
Mark McIntyre

 

[Joseph Dionne]

[..]


This newsgroup discusses the C programming language as defined by the
ISO standard(s) (C99 and C90); older references such as K&R1 are also
topical for historical discussions. If you want to discuss something
that's specific to some system, you can do so in a newsgroup that
discusses that system.

I understand that the name "comp.lang.c" might lead you to think that
we discuss anything and everything having to do with C programming.
We don't. Now you know.

Thanks for the clarification. I'll leave you to your blobviations.

[..]

 

[Jordan Abel]

I posted this the other day but google delayed it by a substantial
amount of time. Being that the post did not appear immediately
(when it usually does), I figured the issue was something else and
hence for my reposting.

Ah. My apologies - I was somewhat agitated at seeing the three messages
all at once, but google's screwups (or their upstreams, as the case may
be) are hardly your fault.

 

[Jordan Abel]

[context is the term "pass by reference]

What do you call the corresponding programming technique? (Ideally,
I'd like to see a pity and language-independent term, just as we use
the term "linked list" regardless of the implementation language.)

If some other language, say C+++ (sic),

Or, say, lisp.

had built-in support for linked lists, would you insist on not using
the term "linked list" in the context of a C program?

Apparently not.

 

[Jordan Abel]

What a terrible comparison. The actual passing mechanism supported
by C is defined by the standard. Because it is a mechanism of the
language. Concepts such as 'linked list' and 'binary tree' are
implemented with the language. Not /into/ the language. So you
compare to a concept not associated with making up the actual
language. Call by value or pass by value is clearly outlined in
section 3.3.2.2 of c89. Which section describes this so called
concept 'pass by reference' or 'call by reference'? I suspect
there is no section as there is no mechanism of such implemented
into the language.

yet there _is_ a technique, which has been described in detail,
which can be implemented with C, and which is used extensively in
the standard library, and you have repeatedly failed to put forth a
better name for it than "pass by reference".

 

[Dik T. Winter]

> Dik T. Winter wrote:
>
>
> Surely not, as Jensen's Device illustrates. (And trying to compile
> it.)

In the context the difference is minor. And I know exactly how call
by name was compiled on the system I did use.

 

[Dik T. Winter]

>
> The distinction is minor when the actual parameter is a variable, but
> not when it is an expression.

I know all that. I have quite a bit of experience with Algol 60 (it was
the first computer language I ever used). My "minor" was intended in
context.

Anyhow the major distinction between call by value, reference, name,
value-return, or whatever is not at the callers side. It is at the
callees side. Even in Algol 68 you could write:
function(argument)
without knowing whether "argument" could be changed or not, unless you
looked at the definition of "function". In this sense C is an improvement
on Algol 68; if I write:
function(argument)
I am sure that argument will not change, at most what argument points to.
In Algol 68 this is quite a bit more subtle.

 

[aegis]

yet there _is_ a technique, which has been described in detail,
which can be implemented with C, and which is used extensively in
the standard library, and you have repeatedly failed to put forth a
better name for it than "pass by reference".

My original post was in reply to your opposition of the claim
that C does not support 'pass by reference'. I thought it was clear
that this was about a mechanism of the language and not
something you implement with the language. If instead,
you mean to say the value of a pointer object can
also be called a reference and that when passing it to
a function therefore qualifies the language as supporting
'pass by reference', then I think that you are confused. What
you really want to say is 'pass a reference'. I know this is
an international forum so English may not be your native
language but do you understand the difference?

 

[Chris Dollin]

I coined it just now because I think the programming technique deserves
a name. What would you call the technique used in the list of standard
library functions i named upthread?

If you could be more explicit about the list (I looked back a way but
found it not), then I could offer a name.

I note that the pass by / call by distinction you offer is idiosyncratic
to you.

 

[Chris Dollin]

Here are a couple of questions for those of you who insist that the
term "pass by reference" should apply only to a built-in language
feature:

What do you call the corresponding programming technique? (Ideally,
I'd like to see a pity and language-independent term, just as we use
the term "linked list" regardless of the implementation language.)

"passing a pointer". Or "indirection". Or "passing a reference". Or
even (as I'm an old fogey who defaults, as we have seen, to the term
"call by reference" for the language feature) "pass by reference",
but since that appears to be becomming the term for the feature, I'd
best change my habits.

If some other language, say C+++ (sic), had built-in support for
linked lists, would you insist on not using the term "linked list" in
the context of a C program?

No. I'd just say that C+++ "had" linked lists, and C didn't. (Actually
I'd be likely to say that they had/had not "lists", because my own
idiosyncracy is to think of "list" as /meaning/ linked list; these
funny psuedo-arrays that eg Java call "lists" always seem to me to
be misnamed. But I know that's Just Me.)

I'd try to be /clear/, in any case. "Well, C+++ has linked lists as
a built-in feature; C doesn't have them, but you can implement them,
or something pretty close."

 

[M.B]

"passing a pointer". Or "indirection". Or "passing a reference". Or
even (as I'm an old fogey who defaults, as we have seen, to the term
"call by reference" for the language feature) "pass by reference",
but since that appears to be becomming the term for the feature, I'd
best change my habits.


No. I'd just say that C+++ "had" linked lists, and C didn't. (Actually
I'd be likely to say that they had/had not "lists", because my own
idiosyncracy is to think of "list" as /meaning/ linked list; these
funny psuedo-arrays that eg Java call "lists" always seem to me to
be misnamed. But I know that's Just Me.)

I'd try to be /clear/, in any case. "Well, C+++ has linked lists as
a built-in feature; C doesn't have them, but you can implement them,
or something pretty close."

Does this answer this long argument
http://c-faq.com/ptrs/passbyref.html

 

[Jordan Abel]

My original post was in reply to your opposition of the claim that C
does not support 'pass by reference'. I thought it was clear that this
was about a mechanism of the language and not something you implement
with the language. If instead, you mean to say the value of a pointer
object can also be called a reference and that when passing it to a
function therefore qualifies the language as supporting 'pass by
reference', then I think that you are confused. What you really want
to say is 'pass a reference'.

yes - you "pass a reference" _by which reference_ you are thus passing
the object whose address is taken. thus "pass by [that] reference". the
'reference' or 'pointer' is something you are _using_ as a mechanism to
pass something, which is why the word "by" is used. The only difference
is whether you, the programmer, are doing it, vs the compiler doing it.

I know this is an international forum so English may not be your
native language but do you understand the difference?

I think _you_ are the one who is not looking at the actual meanings of
the words, and unjustifiably seeing the phrase "pass by reference" as
indivisible.

 

[Jordan Abel]

"passing a pointer". Or "indirection". Or "passing a reference". Or
even (as I'm an old fogey who defaults, as we have seen, to the term
"call by reference" for the language feature) "pass by reference",
but since that appears to be becomming the term for the feature, I'd
best change my habits.


No. I'd just say that C+++ "had" linked lists, and C didn't. (Actually
I'd be likely to say that they had/had not "lists", because my own
idiosyncracy is to think of "list" as /meaning/ linked list; these
funny psuedo-arrays that eg Java call "lists" always seem to me to
be misnamed. But I know that's Just Me.)

I'd try to be /clear/, in any case. "Well, C+++ has linked lists as
a built-in feature; C doesn't have them, but you can implement them,
or something pretty close."

But saying "C doesn't have linked lists, this isn't C+++" in response to
EVERY mention of "linked list", even when it was clear that it wasn't
about a language feature, would be widely seen as a troll, wouldn't it?