p 161...File access

[mdh]

Hi All,
There is a line in the discussion of K&R (section 7-5) that says ...
(end of 2nd paragraph, about the middle of the page)...in connection
with the description of getc and putc...that

"Like getchar and putchar, getc and putc may be macros instead of
functions"

Now, recently, I asked why va_list, va_arg, va_start etc were macros,
and the answers included these two insights from KT;

>>>>>>>

a function can't modify an argument.

Â*A C function cannot take 
a type name as an argument
<<<<<<<

Is the significance of this statement ( ie relating to putchar/
getchar) related to macros in va_list at all. And if not, what
significance/insight should I attribute to this statement?
Thanks as usual.

[Gordon Burditt]

>There is a line in the discussion of K&R (section 7-5) that says ...

>(end of 2nd paragraph, about the middle of the page)...in connection
with the description of getc and putc...that

"Like getchar and putchar, getc and putc may be macros instead of
functions"

If they are macros, it's usually for efficiency reasons.

You need to KNOW if getc() and putc() might be macros for
reasons such as:
FILE *f = &array_of_open_files[0];

c = getc(f++);
might not do what you expect it to do because the first argument
of getc() might be evaluated more than once, causing unexpected
results. This is not an issue if getc() *MUST* be a function.

>Now, recently, I asked why va_list, va_arg, va_start etc were macros,
and the answers included these two insights from KT;

>>>>>>>>

a function can't modify an argument.

Â*A C function cannot take 
a type name as an argument
<<<<<<<

>Is the significance of this statement ( ie relating to putchar/
getchar) related to macros in va_list at all.

Have you ever expected getc(unsigned long *) to work correctly?

No. There are lots of different reasons why something might be a macro,
and those reasons need not be related.

>And if not, what
significance/insight should I attribute to this statement?

Which statement?

Code may be considered 'dead' because it can never be reached.
Cats may be considered 'dead' because they have been shot through the
head with a .45 .

Do you think these two statements are related?

[Martien Verbruggen]

On Sun, 28 Sep 2008 23:09:28 -0500,
Gordon Burditt <go***********@burditt.orgwrote:

>>There is a line in the discussion of K&R (section 7-5) that says ...
(end of 2nd paragraph, about the middle of the page)...in connection
with the description of getc and putc...that

"Like getchar and putchar, getc and putc may be macros instead of
functions"

If they are macros, it's usually for efficiency reasons.

You need to KNOW if getc() and putc() might be macros for
reasons such as:
FILE *f = &array_of_open_files[0];

c = getc(f++);
might not do what you expect it to do because the first argument
of getc() might be evaluated more than once, causing unexpected
results. This is not an issue if getc() *MUST* be a function.

If a library function is implemented as a macro, it is not allowed to
evaluate its arguments more than once.

Excerpt from 7.1.4 p1:

Any invocation of a library function that is implemented as a macro shall
expand to code that evaluates each of its arguments exactly once, fully
protected by parentheses where necessary, so it is generally safe to use
arbitrary expressions as arguments.162)

Footnote 162 says: Such macros might not contain the sequence points that the
corresponding function calls do

(This is copied from WG14/N1256. The C99 standard itself has identical
wording, except that the footnote number is 156)

In other words, the code above is guaranteed to behave identical whether
getc() is a macro or a function.
Martien
--
|
Martien Verbruggen | I think there is a world market for maybe
| five computers. -- Thomas Watson, chairman
| of IBM, 1943

[Ben Pfaff]

Martien Verbruggen <mg**@tradingpost.com.auwrites:

If a library function is implemented as a macro, it is not allowed to
evaluate its arguments more than once.

[...]

In other words, the code above is guaranteed to behave identical whether
getc() is a macro or a function.

It is amazing that you went to all the trouble of quoting all
that without actually looking at the description of the getc
function:

7.19.7.5 The getc function
[...]
2 The getc function is equivalent to fgetc, except that if it
is implemented as a macro, it may evaluate stream more than
once, so the argument should never be an expression with
side effects.

--
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz

[Keith Thompson]

go***********@burditt.org (Gordon Burditt) writes:
[...]

>>Now, recently, I asked why va_list, va_arg, va_start etc were macros,
and the answers included these two insights from KT;

>>>>>>>>>

a function can't modify an argument.

ÂÂ*A C function cannot take 
a type name as an argument
<<<<<<<

Gordon:

The above (starting with "Now, recently") was written by mdh. He
quoted something I had written, and he attributed it to me ("insights
from KT"). You left *that* indirect attribution in place.

Nothing bad happened.

Thus endeth the lesson.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[mdh]

On Sep 29, 12:55*am, Keith Thompson <[e-mail]:

[e-mail] (Gordon Burditt) writes:

[...]

>Now, recently, I asked why va_list, va_arg, va_start etc were macros,
and the answers included these two insights from KT;

a function can't modify an argument.

>Â*A C function cannot take 
a type name as an argument
<<<<<<<

Hi Keith,
I am still at a little bit of a loss why K&R specifically mentioned
this factoid. There may have been a lesson in the earlier answer, but
it evaded me.

[Martien Verbruggen]

On Sun, 28 Sep 2008 22:40:01 -0700,
Ben Pfaff <bl*@cs.stanford.eduwrote:

Martien Verbruggen <mg**@tradingpost.com.auwrites:

>If a library function is implemented as a macro, it is not allowed to
evaluate its arguments more than once.

[...]

>In other words, the code above is guaranteed to behave identical whether
getc() is a macro or a function.

It is amazing that you went to all the trouble of quoting all
that without actually looking at the description of the getc
function:

7.19.7.5 The getc function
[...]
2 The getc function is equivalent to fgetc, except that if it
is implemented as a macro, it may evaluate stream more than
once, so the argument should never be an expression with
side effects.

I never noticed that before. This seems to be limited to getc, putc,
getwc and putwc. Any others that are exceptions to this rule that I
missed?

Martien
--
|
Martien Verbruggen | If at first you don't succeed, try again.
| Then quit; there's no use being a damn fool
| about it.

[Mike Wahler]

"Gordon Burditt" <go***********@burditt.orgwrote in message
news:sb******************************@posted.inter netamerica...

Cats may be considered 'dead' because they have been shot through the
head

nine times

with a .45 .

:-)

-Mike

[Keith Thompson]

mdh <md**@comcast.netwrites:

On Sep 29, 12:55Â*am, Keith Thompson <[e-mail]:

[...]

>>Now, recently, I asked why va_list, va_arg, va_start etc were macros,
and the answers included these two insights from KT;

>a function can't modify an argument.

>>ÂÂ*A C function cannot take 
a type name as an argument
<<<<<<<

Hi Keith,
I am still at a little bit of a loss why K&R specifically mentioned
this factoid. There may have been a lesson in the earlier answer, but
it evaded me.

I wasn't aware that K&R mentioned it (though it's possible they do).

*I* mentioned it in response to your question about why va_* are macros.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Gordon Burditt]

>>>Now, recently, I asked why va_list, va_arg, va_start etc were macros,

>>>and the answers included these two insights from KT;
>>>>>>
a function can't modify an argument.

ÂÂ*A C function cannot take 
a type name as an argument
<<<<<<<

Gordon:

The above (starting with "Now, recently") was written by mdh. He
quoted something I had written, and he attributed it to me ("insights
from KT"). You left *that* indirect attribution in place.

Are you sure "KT" isn't a reference to a Knowledge Tree web site?

>Nothing bad happened.

Something bad happened. Someone posted the article to which I am
replying, and talked about nothing but attributions, which are
entirely off-topic. Nowhere do any names of posters appear in the
C standard (with the possible exception of Dennis Ritchie).
Yes, this article is just as much an offender.

Attributions are bad because they provoke many of the "regulars"
into talking about the attributions and the people named in them
rather than talking about C. They call each other "trolls" and
trade insults.

Please don't read the attributions. And if you must read the
attributions, don't copy names from them into the body of the
article. The meaning of what was said doesn't change with who said
it.

[Flash Gordon]

Gordon Burditt wrote, On 29/09/08 19:10:

>>>Now, recently, I asked why va_list, va_arg, va_start etc were macros,

Keith Thompson has on many occasions specifically told you that he does
not want his posts quoted without attribution. Since this has often been
done when replying to you I find it unbelievable that you are not aware
of his desire.

>Nothing bad happened.

Something bad happened...

If that is bad, it is something bad happening in response to YOUR
failure to provide attributions.

However, as you are well aware Keith means that no one has sued him as a
result of posting that argument and it did not leed to complaints about
miss-attribution.

<snip>

Attributions are bad because they provoke many of the "regulars"
into talking about the attributions and the people named in them
rather than talking about C. They call each other "trolls" and
trade insults.

It is not the attributions that cause that. After all, such posts are
generally in *direct* response to the person, *not* in response to a
post quoting that person.

Please don't read the attributions. And if you must read the
attributions, don't copy names from them into the body of the
article.

Please ignore Gordon on this matter. The "standard" on news groups is to
attribute quoted material to the poster.

The meaning of what was said doesn't change with who said
it.

No, but how likely it is to be reliable does depend on who posted it. It
also allows one to spot whether it is a debate between just two people
or one with multiple people which can be useful.

For the record, I explicitly deny permission to quote any of the
articles I have ever posted to any news group without attribution. I
also deny permission to quote any of my future articles without attribution.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Keith Thompson]

go***********@burditt.org (Gordon Burditt) writes:

>>>>Now, recently, I asked why va_list, va_arg, va_start etc were macros,
and the answers included these two insights from KT;
>>>>>>>
a function can't modify an argument.

ÂÂÂ*A C function cannot take 
a type name as an argument
<<<<<<<

The above was written by mdh <md**@comcast.net>.

>>
Gordon:

The above (starting with "Now, recently") was written by mdh. He
quoted something I had written, and he attributed it to me ("insights
from KT"). You left *that* indirect attribution in place.

The above was written by me, Keith Thompson <ks***@mib.org>.

Are you sure "KT" isn't a reference to a Knowledge Tree web site?

Yes.

>>Nothing bad happened.

Something bad happened. Someone posted the article to which I am
replying, and talked about nothing but attributions, which are
entirely off-topic. Nowhere do any names of posters appear in the
C standard (with the possible exception of Dennis Ritchie).
Yes, this article is just as much an offender.

Attributions are bad because they provoke many of the "regulars"
into talking about the attributions and the people named in them
rather than talking about C. They call each other "trolls" and
trade insults.

Nonsense. Your deliberate snipping of attributions occasionally
provokes such discussions. If you left them alone, nothing bad would
happen, and this discussion would not be taking place.

Please don't read the attributions. And if you must read the
attributions, don't copy names from them into the body of the
article. The meaning of what was said doesn't change with who said
it.

What I write is judged in part by what I've written before; same for
everyone else here. If Steve Summit writes something, I check my
facts very carefully before publicly disagreeing. If certain other
posters write something, I check my facts very carefully before
agreeing. Furthermore, this newsgroup isn't just a series of factual
statements (or misstatements) made in a vacuum; it's a kind of
community. Knowing who said what makes it a more pleasant place and
makes it easier to follow the discussions.

I understand that you, Gordon Burditt, are not likely to change your
mind on this topic. I only brought it up again because you
(accidentally) left a partial attribution in place, rather than rudely
deleting deleting it. I don't intend to discuss it again, except for
my usual request when I happen to post a followup to something you
wrote.

I, Keith Thompson, wrote this. Permission to quote this, or anything
else I post to Usenet, without attribution is denied. Permission to
quote with proper attribution is granted, as always.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Martin Ambuhl]

Gordon Burditt (Yes, that's whp wrote it; sue me Gordon for attributing
to you your own words.) wrote:

Are you sure "KT" isn't a reference to a Knowledge Tree web site?

Yes, and you are an idiot if think otherwise.

Something bad happened. Someone posted the article to which I am
replying, and talked about nothing but attributions, which are
entirely off-topic.

Something bad happened. You stole other people's words without
attribution. That is anti-social and dishonest.

Attributions are bad because they provoke many of the "regulars"
into talking about the attributions and the people named in them
rather than talking about C. They call each other "trolls" and
trade insults.

That is just incredibly stupid. Proper attribution does not lead to
discussion of attribution. Where do you get off telling such blatant lies?

Please don't read the attributions. And if you must read the
attributions, don't copy names from them into the body of the
article. The meaning of what was said doesn't change with who said
it.

This is not only stupid and dishonest, it violates long-standing usenet
policy. Do not pay any attention to Gordon Burditt: he is ignorant and
anti-social and is trying to entice others into his den of ignorance and
misbehavior.

[dj3vande]

In article <r9************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>Gordon Burditt wrote, On 29/09/08 19:10:

[quoting somebody without attribution:]

>>>>Now, recently, I asked why va_list, va_arg, va_start etc were macros,

Keith Thompson has on many occasions specifically told you that he does
not want his posts quoted without attribution. Since this has often been
done when replying to you I find it unbelievable that you are not aware
of his desire.

Perhaps it's time to start sending cease-and-desist letters?
dave

--
Dave Vandervies dj3vande at eskimo dot com
Oh, and hello to everyone that noticed I wasn't here. Everyone else,
please carry on not caring.
--Randy the Random in the scary devil monastery

[Keith Thompson]

dj******@csclub.uwaterloo.ca.invalid writes:

In article <r9************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>>Gordon Burditt wrote, On 29/09/08 19:10:

[quoting somebody without attribution:]

>>>>>Now, recently, I asked why va_list, va_arg, va_start etc were macros,

Keith Thompson has on many occasions specifically told you that he does
not want his posts quoted without attribution. Since this has often been
done when replying to you I find it unbelievable that you are not aware
of his desire.

Perhaps it's time to start sending cease-and-desist letters?

Nah. His use of my words without attribution is annoying, but I'm
under no obligation to do anything about it, and I choose not to in
this case. I doubt that bringing the legal system into this would be
either appropriate or constructive. This is about rudeness, not legal
liability, Gordon Burditt's absurd claims to the contrary
notwithstanding. I am Keith Thompson, replying to Flash Gordon's
reply to Gordon Burditt. Permission to quote this without attribution
is specifically denied.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jameskuyper]

Gordon Burditt wrote:
....

Attributions are bad because they provoke many of the "regulars"
into talking about the attributions

Well, so does removing attributions.

... and the people named in them
rather than talking about C. They call each other "trolls" and
trade insults.

Have you seen any evidence to suggest that your refusal to attribute
things people said reduces the name calling? People can identify the
people they want to insult just from the style of the things that
other person says. Also, as far as I can tell, the desire to insult
someone here seems to stem primarily from the content of the message,
not the identity of the person who posted it.

Please don't read the attributions. And if you must read the
attributions, don't copy names from them into the body of the
article. The meaning of what was said doesn't change with who said
it.

When it contains first-person pronouns, the meaning most certainly
changes with the identity of the speaker.

Reputation is an important aspect of almost every culture, and that's
because a person's character can, quite legitimately, affect the right
way to think about what that person says; it can even determine
whether or not there's any point in spending time reading what that
person says.

Statements made by people who have a reputation for lying need to be
either ignored outright, or at least examined more carefully for lies
than those of people who have a reputation for honesty.

Statements by people who have a reputation for careless speech need to
be interpreted differently from those by people with a reputation for
speaking precisely - the same exact sentence can mean quite different
things when written by those two different kinds of people.

Statements by people who have a reputation of being experts in a given
area should be taken more seriously, when discussing that area, than
those by people who do not.

Attribution both enables the building of reputations in the first
place, and also enables the legitimate application of a person's
reputation to interpreting words written by that person.

[CBFalconer]

Gordon Burditt wrote:

mdh wrote:

>There is a line in the discussion of K&R (section 7-5) that
says ... (end of 2nd paragraph, about the middle of the page)
...in connection with the description of getc and putc...that

"Like getchar and putchar, getc and putc may be macros instead
of functions"

If they are macros, it's usually for efficiency reasons.

You need to KNOW if getc() and putc() might be macros for
reasons such as:
FILE *f = &array_of_open_files[0];

c = getc(f++);
might not do what you expect it to do because the first argument
of getc() might be evaluated more than once, causing unexpected
results. This is not an issue if getc() *MUST* be a function.

I have reinstalled the attribution that you carelessly omitted.

You know all this. Just read the description of the function:

7.19.7.5 The getc function

Synopsis
[#1]
#include <stdio.h>
int getc(FILE *stream);

Description

[#2] The getc function is equivalent to fgetc, except that
if it is implemented as a macro, it may evaluate stream more
than once, so the argument should never be an expression
with side effects.

Returns

[#3] The getc function returns the next character from the
input stream pointed to by stream. If the stream is at end-
of-file, the end-of-file indicator for the stream is set and
getc returns EOF. If a read error occurs, the error
indicator for the stream is set and getc returns EOF.

You have various ways of ensuring that getc does NOT call a macro,
including placing the call in parentheses. i.e.:

ch = (getc)(f++); /* perfectly legal */

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Martien Verbruggen wrote:

Gordon Burditt <go***********@burditt.orgwrote:

>mdh wrote:

>>There is a line in the discussion of K&R (section 7-5) that
says ... (end of 2nd paragraph, about the middle of the page)
...in connection with the description of getc and putc...that

"Like getchar and putchar, getc and putc may be macros instead
of functions"

If they are macros, it's usually for efficiency reasons.

You need to KNOW if getc() and putc() might be macros for
reasons such as:
FILE *f = &array_of_open_files[0];

c = getc(f++);
might not do what you expect it to do because the first argument
of getc() might be evaluated more than once, causing unexpected
results. This is not an issue if getc() *MUST* be a function.

If a library function is implemented as a macro, it is not allowed
to evaluate its arguments more than once.

.... snip ...

>
In other words, the code above is guaranteed to behave identical
whether getc() is a macro or a function.

No it isn't. The standard contains specific exemptions for getc
and putc.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[vippstar]

On Sep 29, 11:28 pm, CBFalconer <[e-mail]:

<snip>

You have various ways of ensuring that getc does NOT call a macro,
including placing the call in parentheses. i.e.:

ch = (getc)(f++); /* perfectly legal */

While absolutely correct, whenever I'd want a non-macro getc because I
don't want the argument to be evaluated more than once, I'd just use
fgetc.

[dj3vande]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>dj******@csclub.uwaterloo.ca.invalid writes:

>Perhaps it's time to start sending cease-and-desist letters?

Nah. His use of my words without attribution is annoying, but I'm
under no obligation to do anything about it, and I choose not to in
this case. I doubt that bringing the legal system into this would be
either appropriate or constructive. This is about rudeness, not legal
liability, Gordon Burditt's absurd claims to the contrary
notwithstanding.

Probably true.
I was thinking in terms of root causes; the root cause for his
reluctance to maintain attributions seems to be complaints and threats
of lawsuits that he claims to have received when quoting with
attribution, so perhaps if he were to get those results when quoting
without attribution as well, he'd have less reason to cut them out.
(Which would have a particularly elegant symmetry, even if it's not
worth actually doing.)

I am Keith Thompson, replying to

Dave Vandervies's reply to

Flash Gordon's
reply to Gordon Burditt.

An excellent, though probably not intentional, demonstration of how
much easier it is to let the computer handle it for you. (Which of
course only works if everybody else is willing to play nicely.)
dave

--
Dave Vandervies dj3vande at eskimo dot com

>[S]o I just hang-up and swore at them for a good 5 minutes.

The sequence of these actions could be improved upon.
--Bogdan Imandei and Rik Steenwinkel in the scary devil monastery

[Keith Thompson]

dj******@csclub.uwaterloo.ca.invalid writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>>dj******@csclub.uwaterloo.ca.invalid writes:

>>Perhaps it's time to start sending cease-and-desist letters?

Nah. His use of my words without attribution is annoying, but I'm
under no obligation to do anything about it, and I choose not to in
this case. I doubt that bringing the legal system into this would be
either appropriate or constructive. This is about rudeness, not legal
liability, Gordon Burditt's absurd claims to the contrary
notwithstanding.

Probably true.
I was thinking in terms of root causes; the root cause for his
reluctance to maintain attributions seems to be complaints and threats
of lawsuits that he claims to have received when quoting with
attribution, so perhaps if he were to get those results when quoting
without attribution as well, he'd have less reason to cut them out.
(Which would have a particularly elegant symmetry, even if it's not
worth actually doing.)

Tempting, but way too much effort. Perhaps eventually Gordwon will
get tired of so many people complaining about his behavior and/or
notice that the only person here who has claimed to agree with him is
"Kenny McCormack".

> I am Keith Thompson, replying to

Dave Vandervies's reply to

> Flash Gordon's
reply to Gordon Burditt.

An excellent, though probably not intentional, demonstration of how
much easier it is to let the computer handle it for you. (Which of
course only works if everybody else is willing to play nicely.)

Whoops, sorry I left you out.

Note the demonstration that, in the case of an unintentional missing
or incorrect attribution, a brief apology is all that's called for --
and in the presence of such an apology, any legal action would, I
expect, be thrown out of court very quickly. IANAL.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Martien Verbruggen wrote:

On Sun, 28 Sep 2008 22:40:01 -0700,
Ben Pfaff <bl*@cs.stanford.eduwrote:

>Martien Verbruggen <mg**@tradingpost.com.auwrites:

>>If a library function is implemented as a macro, it is not allowed to
evaluate its arguments more than once.

[...]

>>In other words, the code above is guaranteed to behave identical whether
getc() is a macro or a function.

It is amazing that you went to all the trouble of quoting all
that without actually looking at the description of the getc
function:

7.19.7.5 The getc function
[...]
2 The getc function is equivalent to fgetc, except that if it
is implemented as a macro, it may evaluate stream more than
once, so the argument should never be an expression with
side effects.

I never noticed that before. This seems to be limited to getc, putc,
getwc and putwc. Any others that are exceptions to this rule that I
missed?

No.

--
pete