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

[aegis]

Jordan Abel wrote:

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

Passing by reference has to do with passing around actual containers
or in C's case, objects.

I disagree.

We don't do that in C. We instead pass the
values stored in objects around to functions. The standard is clear
here and supports absolutely diddly squat in regards to a concept
called "pass by reference".

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.

--
aegis

[Richard Tobin]

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

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

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]

Keith Thompson wrote:

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

Here, here! Just because K&R describes the process of how a
function is called, i.e. copies are placed on the stack before the
function call, does not imply c is only pass by value.

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]

On 9 Jan 2006 22:32:16 GMT, in comp.lang.c , ri*****@cogsci. ed.ac.uk
(Richard Tobin) wrote:

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

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Joseph Dionne]

Default User wrote:

Keith Thompson wrote:

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

Here, here! Just because K&R describes the process of how a
function is called, i.e. copies are placed on the stack before the
function call, does not imply c is only pass by value.

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

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]

Joseph Dionne <sp******@minds pring.com> writes:

Default User wrote:

Keith Thompson wrote:

Joseph Dionne <jd*****@hotmai l.com> writes:
Here, here! Just because K&R describes the process of how a
function is called, i.e. copies are placed on the stack before the
function call, does not imply c is only pass by value.

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

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.

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

[Mark McIntyre]

On Mon, 09 Jan 2006 23:08:42 GMT, in comp.lang.c , Joseph Dionne
<sp******@minds pring.com> wrote:

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

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Joseph Dionne]

Keith Thompson wrote:

Joseph Dionne <sp******@minds pring.com> writes:

[..]

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]

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

Jordan Abel wrote:

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

>
> Jordan Abel wrote:
>> On 2006-01-07, Keith Thompson <ks***@mib.or g> wrote:
>> > Richard Heathfield <in*****@invali d.invalid> writes:
>> >> Keith Thompson said:
>> >>> (I'm 100% certain that I'm not telling you anything you don't already
>> >>> know; the point is to figure out just where we disagree.)
>> >>
>> >> I'm for whatever makes C easier to understand. Heaven knows it's hard enough
>> >> already, without making it harder.
>> >>
>> >> When you say "pointers" and "pass by reference", yes, OF COURSE I know what
>> >> you mean. But J Random Newbie over there, who already has a hundred new
>> >> concepts buzzing around his head right now and who does not fully
>> >> understand what pointers *are* yet, let alone what they are *for*, is going
>> >> to think "pointers, right, the little * thing, okay, pass-by-reference,
>> >> right, * means pass by reference, which means I can update it, great..."
>> >> and he is going to think he understands things a little better - and then
>> >> he is (eventually) going to wonder why this:
>> >>
>> >> void allocstr(char *s, size_t n)
>> >> {
>> >> s = malloc(n);
>> >>
>> >> if(s == NULL) abort();
>> >> }
>> >>
>> >> doesn't seem to do what he wants.
>> >
>> > Then we need to make it very clear to J Random Newbie that C doesn't
>> > support pass by reference as a languag construct. 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. 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.
>> >
>> > 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).
>>
>> And uses it extensively in the standard library:
>>
>> math.h: frexp, modf,
>> stdio.h: fscanf (and friends), fprintf (and friends, for %n), fgetpos,
>> fsetpos,
>> stdlib.h: strtol (and friends),
>> time.h: mktime, time, asctime, asctime, ctime, gmtime, localtime
>>
>> Possibly others i've missed from later standards (this was written by
>> grepping c89 for (.*\*.*) and manually selecting the functions that use
>> this mechanism.
>
> This is suppose to be suggestive of C supporting
> pass by reference? You will have to try harder than that.
> Chapter and verse please!

You just said the same thing, in response to the same message, three
different times, in three different ways. Did you forget about your two
earlier posts?

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.