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

[Richard Heathfield]

Joe Wright said:

Jordan Abel wrote:

[...] time() takes its argument by reference [as do many other
functions in time.h, for historical reasons] You are conflating a
generic concept with a specific feature C++ has that C does not.

I may have to look this up because an exact example eludes me right now.

You needn't bother - Jordan is wrong about time() which does not in fact
take its argument by reference. It takes its parameter by value. The
argument is evaluated, and that value passed to time(). It's just like any
other parameter-taking C function in that regard.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Joseph Dionne said:

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.

Case closed, I think, as far as Mr Dionne is concerned.

Troll, idiot, or newbie. In this case, I don't really see the point in
trying to distinguish between them.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Joseph Dionne said:

Look who is being humorous. Sir, in you example, "buf" will never change
is
memory value, even *if* you pass it by reference, "& buf".

That isn't passing buf by reference. It's passing the address of buf by
value.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

Joseph Dionne <jd*****@hotmai l.com> writes:

Keith Thompson wrote:

Joseph Dionne <jd*****@hotmai l.com> 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.

[...] There are two "&" operators in C, a binary operator (taking two
operand) that performs a bitwise logical AND, and a unary operator
(taking one operand) that yields the address of its operand.
The expressions "&pointer" and "& pointer" are precisely equivalent.
The amount of whitespace between the operator and the operand is not
significant. The compiler is able to distinguish between unary and
binary "&" by the context in which it appears.
The unary "&" operator doesn't yield the contents of a pointer; it
yields the address of an object. [...] I suggest you read a good C textbook (K&R2 is very good). You have a
lot of things to unlearn.
(Or if you're doing this deliberately, please please please go away;
it's not amusing.)
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.

I didn't say that C doesn't support pass by reference. I said that C
doesn't *directly* support pass by reference, but that a programmer
can *implement* pass by reference using the features of the language.
Your continued reference to 'object' during replies proves my assertions --
recent OOP development (decades ago implemented recent, I mean) 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.
What does my use of the term "object" have to do with anything? The C
standard defines an "object" as a "region of data storage in the
execution environment, the contents of which can represent values"
(C99 3.14). I wasn't using the term in the sense of object-oriented
programming. (The C++ standard's definition of "object" is similar.)
Show me any authority that shares you "opinion" that c does not "pass
by reference".

C99 6.5.2.2p4:

An argument may be an expression of any object type. In preparing
for the call to a function, the arguments are evaluated, and each
parameter is assigned the value of the corresponding argument. 79)

Footnote 79:

A function may change the values of its parameters, but these
changes cannot affect the values of the arguments. On the other
hand, it is possible to pass a pointer to an object, and the
function may change the value of the object pointed to. A
parameter declared to have array or function type is adjusted to
have a pointer type as described in 6.9.1.

Which is what I've been saying all along.

--
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.

[Keith Thompson]

Richard Heathfield <in*****@invali d.invalid> writes:

Keith Thompson said:

Then we need to make it very clear to J Random Newbie that C doesn't
support pass by reference as a languag construct.

Right.

Don't say that the
"*" means pass by reference; say that the "*" means you're passing a
pointer value, which can be used to do the equivalent of pass by
reference.

To a newbie, the two statements can seem equivalent, especially if he
doesn't know what "pass by reference" is and has to go and look it up. Why
use the phrase at all, when it doesn't add any value?

Until J Random Newbie is able to hold that entire complex
thought in his head, he's not going to be able to be an effective C
programmer.

We can ease that journey by not giving him useless junk to remember.

Pass by reference is a very common and useful programming technique,
one that C supports quite well (though arguably a little more clumsily
than some other languages do).

I know what you're saying, but I think that's an own-foot-shooting way to
say it.

Ok, I see your point. I suppose it depends on the kind of newbie.

Personally, I learned Pascal before I learned C, so I already knew
about pass-by-value and pass-by-reference. From that perspective,
understanding that passing a pointer is the way to emulate
pass-by-reference in C was very important. Things might be different
for a non-programmer learning C.

On the other hand, I'm not sure that C is a good choice for a first
language. In any case, a programmer should *eventually* understand
the concepts of pass-by-value and pass-by-reference. And I tend to
think that it's at least as important to use C (or any language) as a
vehicle for learning about programming as it is to learn the details
of the language itself.

--
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.

[Netocrat]

On Sun, 08 Jan 2006 07:14:20 +0000, Keith Thompson wrote:
[...]

I didn't say that C doesn't support pass by reference. I said that C
doesn't *directly* support pass by reference, but that a programmer
can *implement* pass by reference using the features of the language.
[...] C99 6.5.2.2p4:

An argument may be an expression of any object type. In preparing
for the call to a function, the arguments are evaluated, and each
parameter is assigned the value of the corresponding argument. 79)

Footnote 79:

A function may change the values of its parameters, but these
changes cannot affect the values of the arguments. On the other
hand, it is possible to pass a pointer to an object, and the
function may change the value of the object pointed to. A
parameter declared to have array or function type is adjusted to
have a pointer type as described in 6.9.1.

Which is what I've been saying all along.

- in both debates it's often argued that "C does not support the
concept directly, but supports its implementation trivially". In the case
of multi-dimensional arrays, the Standard contradicts this argument since
it explicitly describes a C array declared with more than one index as
multi-dimensional.

In the case of pass by reference, the opposite seems to be true: both
the Standard and its predecessor, K&R, explicitly describe C's parameter
passing as by value.

I think it's reasonable though to refer to C's simulation of this concept
as "pass by reference" (quote marks included) as a shortcut for a longer
expression similar to "pass the object's address to the function so that
the object's value may be modified", when it's clear that the writer is
not referring to the concept as supported more directly by languages like
C++ and Pascal.

--
http://members.dodo.com.au/~netocrat

[Netocrat]

On Sun, 08 Jan 2006 08:59:41 +0000, Netocrat wrote:
[slip-of-the-finger posted an article still being drafted; try again]

On Sun, 08 Jan 2006 07:14:20 +0000, Keith Thompson wrote:
[...]

I didn't say that C doesn't support pass by reference. I said that C
doesn't *directly* support pass by reference, but that a programmer can
*implement* pass by reference using the features of the language.

You've written something very similar in the past about multidimensiona l
arrays. On that occasion I disagreed because the Standard contradicts it.
On this occasion, I agree with your analysis as it seems to be supported
by both the Standard and K&R.

[omit wafflier wordage of draft post]

--
http://members.dodo.com.au/~netocrat

[Chuck F.]

Nelu wrote:

.... snip ...
type is int, you send a pointer to int, int is changed in the function. The functions doesn't tell you that it needs an int to change an int. It tells you it needs a pointer to int that it can't change.
Although you can consider &int a reference to an int, the function doesn't ask for a reference but for a type which is called "pointer to int" and what you send is the value of a pointer to int type.

Please fix your right hand margin. Lines must never exceed 80
chars according to standards, and prefereably should not exceed
about 65 or so (to allow for quote marks).

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>

[Chuck F.]

Keith Thompson wrote:

.... snip ...
Personally, I learned Pascal before I learned C, so I already
knew about pass-by-value and pass-by-reference. From that
perspective, understanding that passing a pointer is the way to
emulate pass-by-reference in C was very important. Things might
be different for a non-programmer learning C.

On the other hand, I'm not sure that C is a good choice for a
first language. In any case, a programmer should *eventually*
understand the concepts of pass-by-value and pass-by-reference.
And I tend to think that it's at least as important to use C (or
any language) as a vehicle for learning about programming as it
is to learn the details of the language itself.

Fortunately for JRN the use of pass-by-name has virtually
disappeared. In fact fortunately for most of us, IMO.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>

[Jordan Abel]

On 2006-01-08, Richard Heathfield <in*****@invali d.invalid> wrote:

Joe Wright said:

Jordan Abel wrote:

[...] time() takes its argument by reference [as do many other
functions in time.h, for historical reasons] You are conflating a
generic concept with a specific feature C++ has that C does not.
I may have to look this up because an exact example eludes me right now.

You needn't bother - Jordan is wrong about time() which does not in fact
take its argument by reference. It takes its parameter by value.

It takes a time_t by reference. You are once again refusing to recognize
the existence of the programming technique called "pass by reference" -
if someone started talking about linked lists in here, you wouldn't
object that C doesn't support those, despite the fact that they (unlike
pass by reference) are not used at all by the interface to the standard
library.
The argument is evaluated, and that value passed to time(). It's just
like any other parameter-taking C function in that regard.