*scanf in Harbison and Steele

[George]

In the context of getting my head around the many and various forms of
scanf, James Kuyper informed me that there were several forms of it of
which I was unaware, and Nick advised me to get a Harbison and Steele as a
reference.

It's kind of a good news/bad news thing. I was motivated to look through
my old texts and I found H&S: copyrighted 1984. The only material that
deals with *scanf is § 17.8. I see no references between §17.8 and §13.4,
which discusses vararg and stdarg, where the discussion is marked by ansi
proposals.

Is this H&S too out of date to help me understand the taxonomy of *scanf,
and if so, are there parts of it that are still good? I took Chuck's
advise and began burning my books, based on lack of relevance to
contemporary C. I must say I'm enjoying _The Presidential Papers_ and _The
Best of William Buckley_ as btu's and reading light from my woodburner.
--
George

Bring them on.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

 

[Nick Keighley]

In the context of getting my head around the many and various forms of
scanf, James Kuyper informed me that there were several forms of it of
which I was unaware, and Nick advised me to get a Harbison and Steele as a
reference.

It's kind of a good news/bad news thing.  I was motivated to look through
my old texts and I found H&S: copyrighted 1984.

I thought there were more recent versions of H&S. Mine's dated 1987.

 The only material that deals with *scanf is § 17.8.
yes

 I see no references between §17.8 and §13.4,
which discusses vararg and stdarg, where the discussion is marked by ansi
proposals.

what? Section 13.4 describes varargs.h and stdarg.h. varargs.h is non-
ANSI
and shouldn't be used. stdarg.h is ANSI. My H&S clearly states this.
Why do you need a reference between 17.8 and 13.4? The *scanf()
functions
are quite comprehensible without knowing anything about stdarg. What
are you having difficulty with?

Is this H&S too out of date

well it *is* dated but I still find it quite usable. It clearly
marks the non-ANSI bits so I don't use them.

[...] to help me understand the taxonomy of *scanf,

what do *you* think "taxonomy" means? What is is it about *scanf()
you don't understand? Is the Dinkum link I gave you any good?

and if so, are there parts of it that are still good?  I took Chuck's
advise and began burning my books, based on lack of relevance to
contemporary C.  I must say I'm enjoying _The Presidential Papers_ and _The
Best of William Buckley_ as btu's and reading light from my woodburner.

BTUs... So your first language *is* english! How surprising.

 

[Martin Ambuhl]

I thought there were more recent versions of H&S. Mine's dated 1987.

And my cpy (5th ed.) is dated 2002, and covers the C99 additions.

what? Section 13.4 describes varargs.h and stdarg.h. varargs.h is non-
ANSI
and shouldn't be used. stdarg.h is ANSI. My H&S clearly states this.

§11.4.1 now covers the "Traditional Facilities: varargs.h". "Traditional
C" in H&S means things often seen pre-C89 implementations.

well it *is* dated but I still find it quite usable. It clearly
marks the non-ANSI bits so I don't use them.

It was out of date for the _old_ standard, C89 (ANSI) or C90 (ISO). It
is definitely out of date for C99. George's 1984 copy is at least a
good deal younger than my copy of K&R1.

 

[John Bode]

In the context of getting my head around the many and various forms of
scanf, James Kuyper informed me that there were several forms of it of
which I was unaware, and Nick advised me to get a Harbison and Steele as a
reference.

It's kind of a good news/bad news thing.  I was motivated to look through
my old texts and I found H&S: copyrighted 1984.  The only material that
deals with *scanf is § 17.8.  I see no references between §17.8 and §13.4,
which discusses vararg and stdarg, where the discussion is marked by ansi
proposals.

Is this H&S too out of date to help me understand the taxonomy of *scanf,
and if so, are there parts of it that are still good?  I took Chuck's
advise and began burning my books, based on lack of relevance to
contemporary C.  I must say I'm enjoying _The Presidential Papers_ and _The
Best of William Buckley_ as btu's and reading light from my woodburner.

1984? That's probably 2nd. ed., which is *woefully* out of date. The
most recent edition of H&S is the 5th edition, copyright 2002. You
can get more information at http://www.careferencemanual.com/.

 

[Lew Pitcher]

I am only aware of scanf as being scanf.

What would be examples of two forms of scanf?

scanf()
sscanf()
fscanf()
fwscanf()
vfscanf()
vscanf()
vsscanf()
wscanf()
vfwscanf()
vwscanf()

Have I forgotten any?


--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[jameskuyper]

scanf()
sscanf()
fscanf()
fwscanf()
vfscanf()
vscanf()
vsscanf()
wscanf()
vfwscanf()
vwscanf()

Have I forgotten any?

swscanf(), vswscanf()

 

[CBFalconer]

.... snip ...

It's kind of a good news/bad news thing. I was motivated to look
through my old texts and I found H&S: copyrighted 1984. The only
material that deals with *scanf is § 17.8. I see no references
between §17.8 and §13.4, which discusses vararg and stdarg, where
the discussion is marked by ansi proposals.

Is this H&S too out of date to help me understand the taxonomy of
*scanf, and if so, are there parts of it that are still good? I
took Chuck's advise and began burning my books, based on lack of
relevance to contemporary C. I must say I'm enjoying _The
Presidential Papers_ and _The Best of William Buckley_ as btu's
and reading light from my woodburner.

Well, the C standard was first issued in 1989. It was renumbered
and reissued in 1990, and slightly updated in 1995. Then a
complete revision (and a new standard document) was issued in
1999. That has had some minor revisions issued to it (all of which
can be found in n1256 below).

So, do you think a 1984 H&S is up-to-date?

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (pre-C99)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

 

[CBFalconer]

swscanf(), vswscanf()

From N869.txt:

fscanf function, 7.8.1, 7.19.1, 7.19.6.2, 7.19.6.4,
fwscanf function, 7.19.1, 7.24.2.2, 7.24.2.4, 7.24.2.6,
scanf function, 7.19.1, 7.19.6.4, 7.19.6.11
sscanf function, 7.19.6.7, 7.19.6.14
swscanf function, 7.24.2.4, 7.24.2.8
vfscanf function, 7.19.1, 7.19.6.8, 7.19.6.9
vfwscanf function, 7.19.1, 7.24.2.6, 7.24.3.10
vscanf function, 7.19.1, 7.19.6.8, 7.19.6.11
vsscanf function, 7.19.6.8, 7.19.6.14
vswscanf function, 7.24.2.8
vwscanf function, 7.19.1, 7.24.2.10, 7.24.3.10
wscanf function, 7.19.1, 7.24.2.10, 7.24.2.12, 7.24.3.10

 

[Keith Thompson]

From N869.txt:

fscanf function, 7.8.1, 7.19.1, 7.19.6.2, 7.19.6.4,
fwscanf function, 7.19.1, 7.24.2.2, 7.24.2.4, 7.24.2.6,
scanf function, 7.19.1, 7.19.6.4, 7.19.6.11
sscanf function, 7.19.6.7, 7.19.6.14
swscanf function, 7.24.2.4, 7.24.2.8
vfscanf function, 7.19.1, 7.19.6.8, 7.19.6.9
vfwscanf function, 7.19.1, 7.24.2.6, 7.24.3.10
vscanf function, 7.19.1, 7.19.6.8, 7.19.6.11
vsscanf function, 7.19.6.8, 7.19.6.14
vswscanf function, 7.24.2.8
vwscanf function, 7.19.1, 7.24.2.10, 7.24.3.10
wscanf function, 7.19.1, 7.24.2.10, 7.24.2.12, 7.24.3.10

So the answer to Lew's question would be no; Lew's list, plus pete's
two additions, matches the list from N869.txt (though it's ordered
differently).

 

[James Kuyper]

So the answer to Lew's question would be no; Lew's list, plus pete's
two additions, matches the list from N869.txt (though it's ordered
differently).

Um ... those were my additions, not pete's. it took me nearly a minute
to verify that there were some missing ones, and another 30 seconds to
discover that I had to correct the order of 's' and 'w' prefixes in my
rough draft. I like to have my hard work ;-) properly acknowledged.

 

[Keith Thompson]

Um ... those were my additions, not pete's. it took me nearly a minute
to verify that there were some missing ones, and another 30 seconds to
discover that I had to correct the order of 's' and 'w' prefixes in my
rough draft. I like to have my hard work ;-) properly acknowledged.

Whoops, sorry about that. I miscounted the '>'s. Consider your
grueling seconds of work acknowledged.

 

[George]

Well, the C standard was first issued in 1989. It was renumbered
and reissued in 1990, and slightly updated in 1995. Then a
complete revision (and a new standard document) was issued in
1999. That has had some minor revisions issued to it (all of which
can be found in n1256 below).

So, do you think a 1984 H&S is up-to-date?

No. The time between this and K&R 1 were critical. This book won't
survive the heating season.

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (pre-C99)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

I've seen most of these. I have a hard copy of the FAQs and know that
Ben's from 48820.
--
George

Our Nation must defend the sanctity of marriage.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

 

[George]

I am only aware of scanf as being scanf.

What would be examples of two forms of scanf?

Pete is, as always, exact. I've been kicking around a project that
required a getline facility. At least 5 clc regulars had web solns for
this. (I wished they had taken it one more step to getfile.) Pete's soln
was clean, but I couldn't understand the pointers.

I had a different question though. I'll establish relevance to the subject
later. The difference between fgets and gets is at least that fgets takes
a file pointer as an arg. gets uses stdin.

If you wanted to use fgets and stdin, how do you do it?

Though I've been told that stdin come with the food in C, must you declare:

extern *file stdin;
char *s buffer;
int n;
file * f;

f= stdin;
....
(give values to other declared vars)

LHS = fgets( buffer, n, f);

--
George

To those of you who received honours, awards and distinctions, I say well
done. And to the C students, I say you, too, can be president of the United
States.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

 

[James Kuyper]

George wrote:
....

I had a different question though. I'll establish relevance to the subject
later. The difference between fgets and gets is at least that fgets takes
a file pointer as an arg. gets uses stdin.

That's one key difference. Another difference is that fgets() takes a
count argument, and will not write more than the specified number of
bytes to the buffer, which is the key feature that makes fgets() safer
than gets(). The final differences is that gets() removes the newline
character that caused it to stop reading. fgets() writes that newline to
the output buffer. Depending upon what you're going to do with the
buffer, that might not matter at all. In most such cases in my code, the
newline character doesn't matter at all.

If you wanted to use fgets and stdin, how do you do it?

Though I've been told that stdin come with the food in C, must you declare:

extern *file stdin;

No. First of all, that would be the wrong declaration (it should be
FILE*, not *file). Secondly, you should not define it; that's the job of

char *s buffer;

The 's' is a typo, I hope. If not, you'll have to explain what it is.

int n;
file * f;

f= stdin;

What purpose does 'f' serve? Why not use stdin directly down below?

...
(give values to other declared vars)

I presume that this includes setting buffer to point at an actual block
of memory?

LHS = fgets( buffer, n, f);

There's no need for storing the LHS. It should be either NULL or compare
equal to buffer; if it doesn't, the value is meaningless. So the only
useful thing to do with the return value is to compare it with either
NULL or buffer. You can do that immediately, without bothering to store it.

For reasons I've explained elsewhere today in a different context, I
prefer to compare versus the successful return value, treating all other
values as exceptional cases of some kind.

if(fgets(buffer, n, stdin) == buffer)
{
// Normal processing
}
else if(ferr(stdin))
{
// I/O error handling
}
else
{
// End of file handling.
}

 

[George]

George wrote:
...

That's one key difference. Another difference is that fgets() takes a
count argument, and will not write more than the specified number of
bytes to the buffer, which is the key feature that makes fgets() safer
than gets(). The final differences is that gets() removes the newline
character that caused it to stop reading. fgets() writes that newline to
the output buffer. Depending upon what you're going to do with the
buffer, that might not matter at all. In most such cases in my code, the
newline character doesn't matter at all.


No. First of all, that would be the wrong declaration (it should be
FILE*, not *file). Secondly, you should not define it; that's the job of


The 's' is a typo, I hope. If not, you'll have to explain what it is.

The s was for char star buffer. It's too intentional for me to claim as a
typo.:-( Pointer declarations are not my strong suit.

What purpose does 'f' serve? Why not use stdin directly down below?

It is meant to mimic Chuck's fggets. I don't want to bring up the
varieties of *gets() again. Chuck, Richard, Pete, Eric Sosman and Morris
Dovey have variations on it posted.

I presume that this includes setting buffer to point at an actual block
of memory?


There's no need for storing the LHS. It should be either NULL or compare
equal to buffer; if it doesn't, the value is meaningless. So the only
useful thing to do with the return value is to compare it with either
NULL or buffer. You can do that immediately, without bothering to store it.

For reasons I've explained elsewhere today in a different context, I
prefer to compare versus the successful return value, treating all other
values as exceptional cases of some kind.

if(fgets(buffer, n, stdin) == buffer)
{
// Normal processing
}
else if(ferr(stdin))
{
// I/O error handling
}
else
{
// End of file handling.
}

Thanks, james, I think I've got this now. The thrust of the question is
whether you had to declare stdin or not, to which your answer is, I believe
"don't declare stdin; #include <stdio.h> instead.

I appreciate the lack of ridicule for my other slipshod declarations.
--
George

I have a different vision of leadership. A leadership is someone who brings
people together.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

 

[CBFalconer]

.... snip ...

I had a different question though. I'll establish relevance to
the subject later. The difference between fgets and gets is at
least that fgets takes a file pointer as an arg. gets uses stdin.

Much more than that. First, gets is NEVER a safe call to make.
gets always reads until an 'n' is found, which is discarded and
replaced with a '\0'. By this time it may well have overwritten
the entire OS.

fgets never discards a '\n'. If no final '\n' appears in the
string, you know that the input exceeded the string length, and
more input from the same line is awaiting you. This check can be a
pain.

ggets is non-standard, but was designed to simplify the call as far
as possible, and to always be 'safe'. It is accompanied by fggets,
which accesses any file, while ggets accesses stdin. ggets always
reads the input to the first '\n' (or system error) and discards
the '\n'. The storage is malloced, so the returned string needs to
eventually be freed. ggets is written in purely standard C, and is
available (public domain) at:

<http://cbfalconer.home.att.net/download/ggets.zip>

 

[George]

It was out of date for the _old_ standard, C89 (ANSI) or C90 (ISO). It
is definitely out of date for C99. George's 1984 copy is at least a
good deal younger than my copy of K&R1.

Are there parts of this book that are timeless?

I was a virgin in 1984, but the late eighties were a time when I was off
doing something else. Somehow I don't know things about the late eighties
that everyone else does. My hands were above the Wall in 1986.

It was in Germany that I first heard of the emergence of C. I possessed no
computer and read only the newspapers and the Bible.

Can you speak to a reading of an old H&S, given that I don't want to fork
with my tender understanding of c99?
--
George

A dictatorship would be a heck of a lot easier, there's no question about
it.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/