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(H5DIR, namelist); /* included from mylib.h */
freeFileNames(namelist, n); /* included from mylib.h */

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

[Richard Heathfield]

Jordan Abel said:

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

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

No, it doesn't. It takes a time_t * 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)

[Jordan Abel]

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

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.

"own-foot-shooting" wording is something that C has its fair share of,
so best not to cast the first stone. See "equivalence of pointers and
arrays" (in, of course, all but three contexts), %f in printf vs scanf
(traceable to the problem of float-to-double argument promotion in
general), the example rand(), etc, etc.

To name an issue that recently came up in here, I think it would have
been better if %s for scanf took "pointer to array of char" rather than
"pointer to char as first member of array".

In particular, the use of the term "object" in C to refer to something
other than what it means to those familiar with other languages is
comparable to this use of "pass by reference" to refer to a programming
technique rather than the language feature it sometimes means instead.

[Jordan Abel]

On 2006-01-08, Chuck F. <cb********@yahoo.com> wrote:

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

However, see also C Preprocessor macro expansion.

[Jordan Abel]

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

Jordan Abel said:

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

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

No, it doesn't. It takes a time_t * by value.

Which is the means by which it implements a reference to a time_t.
Again, the programming technique (implemented quite easily in C) is
different from the language feature (which C, of course, does not have).

[Keith Thompson]

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

Jordan Abel said:

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

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

No, it doesn't. It takes a time_t * by value.

It does that too.

--
Keith Thompson (The_Other_Keith) 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 Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
<jd*****@hotmail.com> wrote:

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.
Well, jackass, it doesn't. It supports pass by value, and you may pass
the value of a pointer to emulate pass by reference.
Your continued reference to 'object' during replies proves my assertions

no, it proves he has more patience than most folk.

You're a troll.

*plonk*
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 =----

[Mark McIntyre]

On Sun, 08 Jan 2006 00:01:42 GMT, in comp.lang.c , Joseph Dionne
<jd*****@hotmail.com> wrote:

Mark McIntyre wrote:

On Sat, 07 Jan 2006 23:23:22 GMT, in comp.lang.c , Joseph Dionne
<jd*****@hotmail.com> wrote:

So when enough people refer to the period from sunrise to sunshine (the day)
as night, we all need to use their incorrect definition?

If you want to avoid confusion, and being thought of as a pompous ass,
yes IMHO. YMMV. HAND.

Sorry, Mr. McIntyre, software is a precision art, not hand grenades or
horseshoes. It has a history of development that ought not be forgotten or
convoluted by future misrepresentations simply because the originating concept
is difficult to grasp.

I have no clue what that babble means, but then, Trolls rarely make
sense.
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 =----

[Jordan Abel]

On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:

On Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
<jd*****@hotmail.com> wrote:

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.

Well, jackass, it doesn't. It supports pass by value, and you may pass
the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

[Chris Torek]

In article <sl**********************@random.yi.org>
Jordan Abel <ra*******@gmail.com> wrote:

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

The phrase "programming technique" is a little bit slippery (in
much the same sense that an elephant is a little bit large :-) ).
C does not have garbage collection either, but you can "emulate"
it by replacing all operations of the form:

p = malloc(nbytes);
...
q = p;
...
q = r;
...
free(q);
...

with:

record_release(p); p = malloc(nbytes); record_ref(p);
...
record_release(q); q = p; record_ref(q);
...
record_release(q); q = r; record_ref(q);
...
record_release(q); free(q); q = NULL; /* for future record_release */

(make sure that p==NULL and q==NULL initially, of course).

If you do this, would you claim that C now "has" garbage collection?

You can emulate by-reference more easily than you can emulate
automatic garbage collection. Does the difficulty of emulation
play a role in deciding whether the language "has" the thing being
emulated?
--
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.

[Richard Tobin]

In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:

That's not "emulating pass by reference", that is passing by reference.

You will find yourself talking at cross-purposes if you take that
approach, since most people don't take "has call-by-reference" to mean
"can achieve the effect of call-by-reference by use of a pointer".

You're well on your way to the Turing tar-pit.

-- Richard

[Chad]

<OT>
foo
</OT>

Chad

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:

That's not "emulating pass by reference", that is passing by reference.

You will find yourself talking at cross-purposes if you take that
approach, since most people don't take "has call-by-reference" to mean
"can achieve the effect of call-by-reference by use of a pointer".

You're well on your way to the Turing tar-pit.

The phrase wasn't "has call-by-reference" (referring to the C
language), it was "is passing by referenece" (referring to the
technique of passing a pointer to an object to allow a function to
modify the object).

C doesn't "have" linked lists, but in a program using the usual
technique involving structures and pointers, the linked lists are real
linked lists.

--
Keith Thompson (The_Other_Keith) 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.

[M.B]

Keith Thompson wrote:

"M.B" <mb*******@gmail.com> writes:

Chuck F. wrote:

M.B wrote:
> sorry if thjis is a duplicate reply...
>
> I guess this is a scope issue for variable "namelist" I suggest
> to change the function int getFileName(char *,struct dirent
> ***); and make necessary changes to code. it may work fine
>
> bcoz scandir i guess sets "struct dirent **" itself. if its
> global all is fine, but local variables 0 its problem-same as
> pass by value

Please use English, not dudespeak, in this newsgroup, and include
adequate context. Between the two your article is totally
meaningless. See below for further advice.
For letting out context, my mistake sorry.
English - hope this is not an english literature group. People want
answers and its enough if they get those in anyway. go hell with
correct English.

You don't need to write flawless English, especially if it doesn't
happen to be your native language, but avoiding abbreviations like "u"
for "you" and "bcoz" for "because" make it *much* easier to understand
you.

Too many SMS s . I will try

Also please check if the advice given in your signature works
correctly.
As far as I know it does. Are you saying it doesn't?

Not for me (and i dont know why).

And finally, noone has time and patience to reply to trolls.
Chuck F. is not a troll. Trust me on this.

I know. Chuck F and others, I apologise

--
Keith Thompson (The_Other_Keith) 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.

[Jordan Abel]

On 2006-01-09, Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:

That's not "emulating pass by reference", that is passing by reference.

You will find yourself talking at cross-purposes if you take that
approach, since most people don't take "has call-by-reference" to mean
"can achieve the effect of call-by-reference by use of a pointer".

Nobody said "has call-by-reference". In the initial context, the mention
of "pass by reference / pass by value" was perfectly clear. It's only
this subsequent arguing in circles that has muddied the waters.

[Default User]

Mark McIntyre wrote:

I have no clue what that babble means, but then, Trolls rarely make
sense.

You're starting to get it. Now, the final enlightenment will be to stop
replying to this cretin.

Brian

[nelu]

Keith Thompson wrote:

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.

http://publib.boulder.ibm.com/infoce...dfhp3b0037.htm
Now, the title of the article refers to both C and C++ so I'm not sure
about it but they say: "Passing a pointer is also known as passing a
value by reference.". But then what would be the difference between *
and & in C++?

[aegis]

Jordan Abel wrote:

On 2006-01-07, Keith Thompson <ks***@mib.org> wrote:

Richard Heathfield <in*****@invalid.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? Are you kidding? Chapter and verse
please!

--
aegis

[aegis]

Jordan Abel wrote:

On 2006-01-07, Keith Thompson <ks***@mib.org> wrote:

Richard Heathfield <in*****@invalid.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.

How does this make your case? This in no way
suggests that C supports pass by reference.
If you keep on insisting that C supports this concept
then I will have to ask you for a chapter and
verse please.

--
aegis

[aegis]

Jordan Abel wrote:

On 2006-01-07, Joe Wright <jo********@comcast.net> wrote:

M.B wrote:

Richard Heathfield wrote:

M.B said:
>its a pass by value v/s pass by reference issue

Since C doesn't have pass by reference, it is clear to me that you are
talking nonsense.

I presume u area c++ guy to talk like this.
pass by reference is a generic term for ur info.
C iimplements this by pointers.

M.B., you clearly don't know what 'pass by reference' means. C doesn't
do it, even with pointers. Whether C++ does it is of no interest here.

Yes it does. 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.

No it does not. See "call by value: 3.3.2.2." straight from c89.
Specifically paragraph two. Which states:

"If the expression that denotes the called function has a type that
includes a prototype, the number of arguments shall agree with the
number of parameters. /Each argument shall have a type such that [its
value] may be assigned to an object with the unqualified version of the
type of its corresponding parameter./"

Pass by reference is about passing around actual containers
and not values. The standard is clear here.
There are no two ways about it.

--
aegis

[aegis]

Jordan Abel wrote:

On 2006-01-07, Keith Thompson <ks***@mib.org> wrote:

Richard Heathfield <in*****@invalid.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!

--
aegis

[aegis]

Jordan Abel wrote:

On 2006-01-07, Joe Wright <jo********@comcast.net> wrote:

M.B wrote:

Richard Heathfield wrote:

M.B said:
>its a pass by value v/s pass by reference issue

Since C doesn't have pass by reference, it is clear to me that you are
talking nonsense.

I presume u area c++ guy to talk like this.
pass by reference is a generic term for ur info.
C iimplements this by pointers.

M.B., you clearly don't know what 'pass by reference' means. C doesn't
do it, even with pointers. Whether C++ does it is of no interest here.

Yes it does. 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.

You are the one doing the conflating. C supports pass by value
/only/. See "call by value: 3.3.2.2" from c89.
Specifically paragraph two. Which states:

"If the expression that denotes the called function has a type that
includes a prototype, the number of arguments shall agree with the
number of parameters. /Each argument shall have a type such that [its
value] may be assigned to an object with the unqualified version of the
type of its corresponding parameter./"

Passing by reference has to do with passing around actual
containers or in C's case, objects. 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".

--
aegis

[Joseph Dionne]

Jordan Abel wrote:

On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:

On Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
<jd*****@hotmail.com> wrote:

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.

Well, jackass, it doesn't. It supports pass by value, and you may pass
the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

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.

Under the hood, Pascal and c++ do exactly the same technique. However, I will
concede the syntax in Pascal and c++ supports pass by reference, making it
easier for developers to not "think" about what they code.

I guess learning assembler as my first language has endeared me to the c
language and I *might* be hypersensitive.

[M.B]

Jordan Abel wrote:

On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:

On Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
<jd*****@hotmail.com> wrote:

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.

Well, jackass, it doesn't. It supports pass by value, and you may pass
the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

Ok if your argument is correct,
do you say C has (not emulate) linked lists,trees,....because we can
create them iusing C
In that case C supports object orientation also.

[Jordan Abel]

On 2006-01-08, aegis <ae***@mad.scientist.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.

[Jordan Abel]

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

Jordan Abel wrote:

On 2006-01-07, Keith Thompson <ks***@mib.org> wrote:

> Richard Heathfield <in*****@invalid.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?

[Jordan Abel]

On 2006-01-09, M.B <mb*******@gmail.com> wrote:

Jordan Abel wrote:

On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:

> On Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
> <jd*****@hotmail.com> wrote:
>
>>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.
>
> Well, jackass, it doesn't. It supports pass by value, and you may pass
> the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

Ok if your argument is correct,
do you say C has (not emulate) linked lists,trees,....because we can
create them iusing C
In that case C supports object orientation also.

C neither supports nor does not support it, because it's not a language
feature, it's a programming technique. THE SAME is true for pass by
reference.

"emulate" isn't the proper word. it's something the programmer _can
implement_ in C. Just like a million other things.

[Chris Dollin]

Jordan Abel wrote:

On 2006-01-09, M.B <mb*******@gmail.com> wrote:

Jordan Abel wrote:

On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:
> On Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
> <jd*****@hotmail.com> wrote:
>
>>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.
>
> Well, jackass, it doesn't. It supports pass by value, and you may pass
> the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

Ok if your argument is correct,
do you say C has (not emulate) linked lists,trees,....because we can
create them iusing C
In that case C supports object orientation also.

C neither supports nor does not support it, because it's not a language
feature, it's a programming technique.

No; it's a language feature; that's the use for which the term was
created, and the use it still retains. A language has "call by
reference" when a call f(x) can change the value of the variable
x as a result of assignments in f to the formal parameter corresponding
to x.

It is a point of distinction between Pascal (I speak of the non-Delphic
variety) and C (K&R, 89, and 99) that you can do this in Pascal (by
declaring the formal parameter to be `VAR`) and you can't do it in C
(and you can do it in C++).

You can certainly get a similar /effect/ in C. You can use an argument
type of pointer-to-Spoo instead of Spoo, replace all references to the
formal argument spoo by *spoo, and insert the necessary & in all the calls.
The fact that you have to /do/ this, consistently, everywhere, is part
of the reason for saying that C doesn't "support" (I would say "have",
as "support" is such an unnecessarily vulnerable word) call-by-reference.

The term "call-by-reference" is part of a family of terms [1] describing
the ways in which parameters may pass into and out of procedures. That
any of these ways might /also/ be done explicitly by additional code
in the language - as a technique as opposed to a feature - doesn't make
the terms valueless and the distinctions they draw irrelevant.

[1] Call by value, call by result, call by value-result, call by reference,
call by value, call by name. "Pass by" would have been better ...

--
Chris "believes seventeen improbable things before coffee" Dollin
Seventeen, forty-two - what else is there?

[Jordan Abel]

On 2006-01-09, Chris Dollin <ke**@hpl.hp.com> wrote:

Jordan Abel wrote:

On 2006-01-09, M.B <mb*******@gmail.com> wrote:

Jordan Abel wrote:
On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:
> On Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
> <jd*****@hotmail.com> wrote:
>
>>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.
>
> Well, jackass, it doesn't. It supports pass by value, and you may pass
> the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

Ok if your argument is correct,
do you say C has (not emulate) linked lists,trees,....because we can
create them iusing C
In that case C supports object orientation also.
C neither supports nor does not support it, because it's not a language
feature, it's a programming technique.

No; it's a language feature; that's the use for which the term was
created, and the use it still retains. A language has "call by
reference" when a call f(x) can change the value of the variable
x as a result of assignments in f to the formal parameter corresponding
to x.

What does the use for which the term "call by reference" was created
have to do with the original poster's use of the term "pass by
reference"? [which, i might add, was completely clear in context.]
The term "call-by-reference" is part of a family of terms [1] describing
the ways in which parameters may pass into and out of procedures. That
any of these ways might /also/ be done explicitly by additional code
in the language - as a technique as opposed to a feature - doesn't make
the terms valueless and the distinctions they draw irrelevant.

[1] Call by value, call by result, call by value-result, call by reference,
call by value, call by name. "Pass by" would have been better ...

the use "pass by" instead of "call by" distinguishes the programming
technique from the language feature.

[Chris Dollin]

Jordan Abel wrote:

On 2006-01-09, Chris Dollin <ke**@hpl.hp.com> wrote:

Jordan Abel wrote:

On 2006-01-09, M.B <mb*******@gmail.com> wrote:

Jordan Abel wrote:
> On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:
> > On Sun, 08 Jan 2006 04:51:47 GMT, in comp.lang.c , Joseph Dionne
> > <jd*****@hotmail.com> wrote:
> >
> >>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.
> >
> > Well, jackass, it doesn't. It supports pass by value, and you may
> > pass the value of a pointer to emulate pass by reference.
>
> That's not "emulating pass by reference", that is passing by
> reference. The fact that the language doesn't have special syntax for
> it doesn't mean it's suddenly a different programming technique.

Ok if your argument is correct,
do you say C has (not emulate) linked lists,trees,....because we can
create them iusing C
In that case C supports object orientation also.

C neither supports nor does not support it, because it's not a language
feature, it's a programming technique.

No; it's a language feature; that's the use for which the term was
created, and the use it still retains. A language has "call by
reference" when a call f(x) can change the value of the variable
x as a result of assignments in f to the formal parameter corresponding
to x.

What does the use for which the term "call by reference" was created
have to do with the original poster's use of the term "pass by
reference"? [which, i might add, was completely clear in context.]

Because "pass by reference" means - as far as I am aware - "call by
reference" (and vice versa). "call by reference" is the earlier term,
the one which comes to my fingers; sorry if I've injected confusion
by using one rather than t'other.

The term "call-by-reference" is part of a family of terms [1] describing
the ways in which parameters may pass into and out of procedures. That
any of these ways might /also/ be done explicitly by additional code
in the language - as a technique as opposed to a feature - doesn't make
the terms valueless and the distinctions they draw irrelevant.

[1] Call by value, call by result, call by value-result, call by
[reference,
call by value, call by name. "Pass by" would have been better ...

the use "pass by" instead of "call by" distinguishes the programming
technique from the language feature.

That's interesting distinction, but the only place I ever seen it made
is in your post - have you a (preferably online) reference to update me?

--
Chris "believes seventeen improbable things before coffee" Dollin
Seventeen, forty-two - what else is there?

[Dik T. Winter]

In article <sl**********************@random.yi.org> Jordan Abel <ra*******@gmail.com> writes:

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

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

I disagree.

The distinction between passing by reference and passing by value is
that at the callers end you can not distinguish the two, it is at
the callees end that the two are distinguished. So in Algol 60
(which has proper pass by reference (actually pass by name, but the
distinction is minor) and pass by value), you can not see from the
line:
routine(argument)
whether the argument is passed by reference or by value. Note also
that in some languages (Fortran) pass by reference is indistinguishable
from pass by value-return (i.e. the value of the argument is passed to
the routine and when the routine terminates a new value is assigned to
the argument).

In C pass by references is only performed with array's (but it is actually
simulated by The Rule).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Chris Dollin]

Dik T. Winter wrote:

The distinction between passing by reference and passing by value is
that at the callers end you can not distinguish the two, it is at
the callees end that the two are distinguished. So in Algol 60
(which has proper pass by reference (actually pass by name, but the
distinction is minor)

(snip)

Surely not, as Jensen's Device illustrates. (And trying to compile
it.)

--
Chris "believes seventeen improbable things before coffee" Dollin
Seventeen, forty-two - what else is there?

[Richard Tobin]

In article <Is********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote:

(which has proper pass by reference (actually pass by name, but the
distinction is minor) and pass by value)

The distinction is minor when the actual parameter is a variable, but
not when it is an expression. In the latter case you have something
like a closure (traditionally called a "thunk" in this context).

Or was your use of "proper" meant to imply that pass by reference
ought to work like this?

-- Richard

[Jordan Abel]

On 2006-01-09, Chris Dollin <ke**@hpl.hp.com> wrote:

the use "pass by" instead of "call by" distinguishes the programming
technique from the language feature.

That's interesting distinction, but the only place I ever seen it made
is in your post - have you a (preferably online) reference to update me?

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?

[Michael Wojcik]

In article <sl**********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:

Well, jackass, it doesn't. It supports pass by value, and you may pass
the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

I'm with Mark, Richard, and Chris on this. Aside from Mr Dionne's
rather confused comments, this thread appears to hang largely on the
question of how strictly one defines the term "pass by reference".
You appear to hold that it covers any "technique" whereby a
"reference" to a variable is passed. I'd call that, at best,
"passing a reference" (where in this context "reference" is an
informal, and not very useful, term for "pointer to an object of the
appropriate type").

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.

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

The presence of those seeking the truth is infinitely preferable to
the presence of those who think they've found it. -- Terry Pratchett

[Richard Tobin]

In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-09, Chris Dollin <ke**@hpl.hp.com> wrote:

the use "pass by" instead of "call by" distinguishes the programming
technique from the language feature.

That's interesting distinction, but the only place I ever seen it made
is in your post - have you a (preferably online) reference to update me?

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?

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

-- Richard

[Jordan Abel]

On 2006-01-09, Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-09, Chris Dollin <ke**@hpl.hp.com> wrote:

the use "pass by" instead of "call by" distinguishes the programming
technique from the language feature.

That's interesting distinction, but the only place I ever seen it made
is in your post - have you a (preferably online) reference to update me?

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?

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

Regardless, I think the original post (which was not mine) was clear to
all involved, and was called out entirely for the sake of nitpicking as
such.

[Keith Thompson]

Joseph Dionne <jd*****@hotmail.com> writes:

Jordan Abel wrote:

[...]

That's not "emulating pass by reference", that is passing by
reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

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.

If so, are you referring to K&R1 or K&R2, and can you provide a page
or section number?

I don't have my copies of K&R 1&2 handy, though I will later today.
There's no reference to "stack" in the errata at
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>. If it really does
talk about "the stack", perhaps there should be.

Leaving stack questions aside, I'll say for the Nth time that C's
parameter passing is *only* pass by value; pass by reference can be
implemented by the programmer using pointers (and the technique is
used in several places in the standard library).

--
Keith Thompson (The_Other_Keith) 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]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-09, Chris Dollin <ke**@hpl.hp.com> wrote:

the use "pass by" instead of "call by" distinguishes the programming
technique from the language feature.

That's interesting distinction, but the only place I ever seen it made
is in your post - have you a (preferably online) reference to update me?

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?

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.

--
Keith Thompson (The_Other_Keith) 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]

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

In article <sl**********************@random.yi.org>, Jordan Abel
<ra*******@gmail.com> writes:

On 2006-01-08, Mark McIntyre <ma**********@spamcop.net> wrote:

>
> Well, jackass, it doesn't. It supports pass by value, and you may pass
> the value of a pointer to emulate pass by reference.

That's not "emulating pass by reference", that is passing by reference.
The fact that the language doesn't have special syntax for it doesn't
mean it's suddenly a different programming technique.

I'm with Mark, Richard, and Chris on this. Aside from Mr Dionne's
rather confused comments, this thread appears to hang largely on the
question of how strictly one defines the term "pass by reference".
You appear to hold that it covers any "technique" whereby a
"reference" to a variable is passed. I'd call that, at best,
"passing a reference" (where in this context "reference" is an
informal, and not very useful, term for "pointer to an object of the
appropriate type").

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.

Ok, I think we're all in agreement about what the built-in features of
the C language are (pass-by-value, no pass-by-reference), and about
the usefulness of a certain technique that can be implemented using
lower-level language features (passing a pointer so the called
function can modify the object that it points to, or just to avoid
unnecessarily copying the entire object). (All of us with the
possible exception of Mr. Dionne; he has so far failed to make clear
just what he thinks.)

Now we're down to a question of terminology. The standard doesn't
provide a term for this technique, so we have to fall back to general
programming jargon or plain English.

Someone who programs both in C and in other languages needs to
understand that passing a pointer is the way to implement what can be
done with a built-in feature in certain other languages. Someone who
programs only in C should still have some understanding of programming
in general, particularly of the very common programming technique of
passing an argument to a function in a way that doesn't copy the value
of the argument and that allows the function to modify a specified
object. We need to understand how this technique is implemented in
terms of C pointers being passed by value (copied) into the function,
but it's not useful to ignore the existence of the technique and talk
only about the lower-level constructs used to implement it, any more
than it would be useful to talk only about pointers and structures in
a program that implements a linked list.

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

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?

--
Keith Thompson (The_Other_Keith) 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.

[aegis]

Jordan Abel wrote:

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

Jordan Abel wrote:

On 2006-01-07, Keith Thompson <ks***@mib.org> wrote:
> Richard Heathfield <in*****@invalid.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.

--
aegis

[aegis]

Jordan Abel wrote:

On 2006-01-08, aegis <ae***@mad.scientist.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.org>,
Keith Thompson <ks***@mib.org> 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*****@hotmail.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*****@hotmail.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******@mindspring.com> writes:

Default User wrote:

Keith Thompson wrote:

Joseph Dionne <jd*****@hotmail.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_Keith) 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******@mindspring.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******@mindspring.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.scientist.com> wrote:

Jordan Abel wrote:

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

>
> Jordan Abel wrote:
>> On 2006-01-07, Keith Thompson <ks***@mib.org> wrote:
>> > Richard Heathfield <in*****@invalid.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.