20 May
2020
20 May
'20
1:45 a.m.
On Sat, May 16, 2020 at 11:39:54AM -0600, Warner Losh wrote:
On Sat, May 16, 2020 at 10:28 AM Paul Winalski
<paul.winalski(a)gmail.com>
wrote:
In the early days of my involvement with FreeBSD, I went through and fixed
about a dozen cases where getopt was being assigned to a char and then
compared with EOF. I'm certain that this is why. Also EOF has to be a value
that's not representable by a character, or your 0xff bytes would disappear.
I think I remember a code review on one of my patches to du(1), I think,
something about adding an option to ignore specific names when
recursing, and I remember either you or BDE chastising me about
while (ch = getopt(...), ch != EOF) :)
G'luck,
Peter
--
Peter Pentchev roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Fri,
May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
Unfortunately, if c is char on a machine with unsigned chars, or it’s of
type unsigned char, the EOF will never be detected.
- while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */
The function prototype for getchar() is: int getchar(void);
It returns an int, not a char. In all likelihood this is specifically
*because* EOF is defined as -1. The above code works fine if c is an
int. One always has to be very careful when doing a typecast of a
function return value.