segfault w/ block, but not file scope

[Dieter]

Hi.

In the snippet of code below, I'm trying to understand why when the

struct dirent ** namelist

is declared with "file" scope, I don't have a problem freeing the
allocated memory. But when the struct is declared in main (block scope)
it will segfault when passing namelist to freeFileNames() .

Since this seems to be just a matter of my understanding scope and
pointer parameter passing better, I only included what thought to be
relevant code. I'll happily provide compilable code if deemed necessary.

Please see commented lines:
struct dirent **namelist; /* file scope works */

int main(void)
{
/* struct dirent **namelist */ /* block scope doesn't work */
int n;

n = getFileNames(H5 DIR, namelist); /* included from mylib.h */
freeFileNames(n amelist, n); /* included from mylib.h */

return 0;
}
Thank you very much for your comments,
Dieter

[Chris Dollin]

Jordan Abel wrote:

On 2006-01-10, aegis <ae***@mad.scie ntist.com> wrote:

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.

Technical terms often have meanings that are not quite the same as
a naive reading would imply. Witness, for example, "call by value".
I'd be quite happy to believe that "pass by reference" was a technical
term that meant something more specific than "a reference was passed",
just as I know that "call by value" doesn't /mean/ "a value was called",
even when in the construct a value /was/ called.

--
Chris "believes seventeen improbable things before coffee" Dollin
But now the machine works, and it's /after/ coffee ..............

[Richard Bos]

Joseph Dionne <sp******@minds pring.com> 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.

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.

Then again, it astounds me how few Unix and/or Windows weenies refer to
"the" way "the" C compiler works, as if their pet systems were the one
and only measure of computer architecture.

Richard

[Keith Thompson]

Chris Dollin <ke**@hpl.hp.co m> writes:
[...]

Technical terms often have meanings that are not quite the same as
a naive reading would imply. Witness, for example, "call by value".
I'd be quite happy to believe that "pass by reference" was a technical
term that meant something more specific than "a reference was passed",
just as I know that "call by value" doesn't /mean/ "a value was called",
even when in the construct a value /was/ called.

Even in plain English, I wouldn't expect "call by value" to mean that
a value is called. The phrase means that something unspecified is
called. The "by value" could mean either that the value does the
calling, or that the value is used in the process of calling.

It's true that technical phrases don't necessarily have exactly the
meaning you'd expect from the literal meanings of their constituent
words, but most of them are fairly close. Usually the technical
definition of a phrase is consistent with the plain meaning, but with
some restrictions.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Michael Wojcik]

In article <ln************ @nuthaus.mib.or g>, Keith Thompson <ks***@mib.or g> writes:

mw*****@newsguy .com (Michael Wojcik) writes:

I agree with Chris (or what I take to be the main point of one of his
posts in this thread): "pass by reference" is more usefully defined
specifically as a syntactic feature of a language. And C does not
have that syntactic feature.
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?

"Passing a reference". I realize this may cause confusion with a
certain C++ feature; too bad. I can't change how C++ decided to
name its features. I don't go out of my way to avoid the word
"template" when discussing C either, even though it names a feature
in C++.

Since references can be implemented using mechanisms other than
pointers, a general term for the technique shouldn't mention
pointers.

The phrase "passing a reference" describes the technique in question
just as precisely as possible, and no more. The recipient gets some
token that it can use to identify the variable to be modified.
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?

Why in the world would I? Lisp has built-in support for linked
lists, and that doesn't prevent me from using the term. My
objection to applying "pass-by-reference" to C has nothing to do
with its presence in other languages (except insofar as that
presence has led to the use of the term in the first place).

"Pass-by-reference" (and "call-by-reference") is a term of art of
long standing, and it historically has usually referred to a
mechanism for passing a reference which is implemented in the
syntax of the language. As I wrote in my previous post, I think
it's more useful to preserve both of those attributes in its
definition than it is to drop the latter one. Doing so preserves
an important and useful distinction, as Richard and others have
argued in this thread.

--
Michael Wojcik mi************@ microfocus.com

Push up the bottom with your finger, it will puffy and makes stand up.
-- instructions for "swan" from an origami kit

[Chris Torek]

`But "glory" doesn't mean "a nice knock-down argument",' Alice objected.

`When *I* use a word,' Humpty Dumpty said, in a rather scornful tone,
`it means just what I choose it to mean -- neither more nor less.'

`The question is,' said Alice, `whether you *can* make words mean so
many different things.'

`The question is,' said Humpty, `which is to be master -- that's all.'

(see <http://www.sabian.org/Alice/lgchap06.htm>).

Chris Torek wrote:

... C remains pass-by-value. The gimmick is that the "value" of
an array is a pointer to the array's first element. In:

void f(void) {
char buf[100];
char *p;

p = buf;

we attempt to copy the "value" of buf -- an array -- to the pointer
variable p. The "value" of the array is a pointer to the array's
first element, so this sets p to point to &buf[0]. ... [Passing "buf" to a function g() likewise provides the value &buf[0].] Within g(), as for any simulation of by-reference in C, we have to
use the unary "*" operator in order to write to buf[0]:

void g(char * ptr) {
* ptr = 42;
...
}

and if we fail to prefix "ptr" with the unary "*" operator when
assigning, we will "re-bind" it so that it no longer points to
"buf" at all ...

In article <o9************ *****@newsread3 .news.atl.earth link.net>
Joseph Dionne <jd*****@hotmai l.com> wrote:Look who is being humorous. Sir, in you example, "buf" will never
change is memory value, even *if* you pass it by reference, "& buf".
[I assume "is memory value" is a typo for "its memory value".]

First, I must continue to insist that passing "&buf" does not pass
buf by-reference, as the term "by-reference" is used in compiler
circles. It passes the value &buf by value, which is what one
would expect, since C passes all parameter by value. Note that
the type of &buf differs from the type of "the value of buf" --
&buf has type (char (*)[100]), as one can see from the following:

% cat t.c
void f(void) {
char buf[100];
char *p1;
char (*p2)[50];
char (*p3)[100];

p1 = &buf; /* line 7 - draws a diagnostic */
p2 = &buf; /* line 8 - draws a diagnostic */
p3 = &buf; /* line 9 - no diagnostic */
}
% strictcc -O -c t.c
t.c: In function `f':
t.c:7: error: assignment from incompatible pointer type
t.c:8: error: assignment from incompatible pointer type
%

Second -- but perhaps even more important -- in a very real sense
(but not in the quirky C language, where the "value" of an array
is a pointer to the array's first element), the "memory value" of
buf is a sequence of 100 "char"s. Thus, whether in f() or in g(),
if we change any of the 100 array elements, we have in fact changed
the "memory value" of buf. What you mean to say is that we cannot
change the *address* of buf -- neither "buf as a whole" (i.e., we
cannot move the array from addresses A through A+99 on the x86
stack on an actual implementation, to some new set of addresses B
through B+99), nor any element of it. This is of course true.
However, the address, wherever it may be, is not in fact fixed
forever, but only for the lifetime of the given function activation:

% cat t.c
#include <stdio.h>

void f(int r) {
char buf[100];

printf("&buf[0]: %p\n", (void *)&buf[0]);
if (r > 0)
f(r - 1);
}

void g(void) {
char x[20];
f(0);
}

int main(void) {
f(1);
g();
return 0;
}
% strictcc -o t t.c
% ./t
&buf[0]: 0x8047a58
&buf[0]: 0x80479c8
&buf[0]: 0x8047a18
%

Note that three different numbers appeared. On this particular
(x86) implementation, these are addresses on the system-supplied
stack, printed as if via %#x. The system uses linear, byte-addressed
virtual memory, so these are the actual "hardware addresses"
(virtualized, of course) within the process running the program.
In the second, recursive call to f(), there are of course two
"buf"s outstanding in memory, one for each activation; in the third,
there is only one "buf" but its address is different from either
of the previous two because g()'s activation record is occupying
space above it (the x86 stack having a "natural" downward-growing
direction).
I think we all can agree the pascal and c++ support pass by
reference by different syntax. I assert the c uses yet another
syntax to implement pass by reference, nothing more or less.

Unfortunately for you and/or anyone with whom you are trying to
communicate, your definition of what constitutes "pass by reference"
disagrees with the majority in computing science / informatics.
For the rest of us, if special syntax is required on *every*
(de)reference, what we have is not an actual, language-provided,
by-reference mechanism. It is fine to say that C lets us simulate
by-reference via pointers, and when speaking informally, calling
it "by reference" is not completely out of the question (though I
myself would try to stick to the phrase "passing *a* reference")
-- but one should make it clear, if asked, that this is not what
is, in informatics, called "by-reference".

It is also worth pointing out that the distinction does show
through if the function you call, to which you pass a reference,
happens to implement the call as value-result internally and
uses a global variable and you pass the address of that global.
(See my earlier example, elsewhere in this thread.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Michael Wojcik]

In article <sl************ **********@rand om.yi.org>, Jordan Abel <ra*******@gmai l.com> writes:

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.

If we're going to quibble over semantics, could we at least try to
formulate decent arguments? There's ample justification for treating
the phrase "pass by reference" as a term of art.

--
Michael Wojcik mi************@ microfocus.com

Bohemia is only a stage in a man's life, except in the case of fools and
a very few others. It is not a profession. -- Arthur Ransome