Re: bin/12852: Non-standard behavior of fread(3)

1999-07-29 Thread Sheldon Hearn



On Wed, 28 Jul 1999 20:13:18 +0200, Robert Nordier wrote:

 There's no question this needs changing.  An ISO example actually
 reads along the lines of:

The question, though, is whether it needs changing _now_, or whether
this'll break a number of critical utilities that rely on the broken
behaviour. I can't imagine the latter case being true, but I thought it
safe to put to question before folks with more experience. :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: bin/12852: Non-standard behavior of fread(3)

1999-07-29 Thread Sheldon Hearn


On Wed, 28 Jul 1999 20:13:18 +0200, Robert Nordier wrote:

 There's no question this needs changing.  An ISO example actually
 reads along the lines of:

The question, though, is whether it needs changing _now_, or whether
this'll break a number of critical utilities that rely on the broken
behaviour. I can't imagine the latter case being true, but I thought it
safe to put to question before folks with more experience. :-)

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: bin/12852: Non-standard behavior of fread(3)

1999-07-28 Thread Sheldon Hearn


Hi folks,

Could someone have a look at the patch proposed on PR 12852? I
understand the motivation, since it seems reasonable to me that ferror()
should return EBADF after an attempt to read from stdout. At the moment,
ferror() returns 0 after an attempt to read from stdout.

Thanks,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: bin/12852: Non-standard behavior of fread(3)

1999-07-28 Thread Robert Nordier

Sheldon Hearn wrote:
 
 Could someone have a look at the patch proposed on PR 12852? I
 understand the motivation, since it seems reasonable to me that ferror()
 should return EBADF after an attempt to read from stdout. At the moment,
 ferror() returns 0 after an attempt to read from stdout.
 
There's no question this needs changing.  An ISO example actually
reads along the lines of:

while (!feof(fp)  !ferror(fp))
fscanf(fp, ...);

with no further provision for error-detection.  Applied to stdout,
this never terminates.

The SVID wording is more definite than ISO in discussing this ("less
than nitems only if a read error or end-of-file is encountered"),
but mostly the present behavior just conflicts with sense and
practice.

-- 
Robert Nordier


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: bin/12852: Non-standard behavior of fread(3)

1999-07-28 Thread Sheldon Hearn

Hi folks,

Could someone have a look at the patch proposed on PR 12852? I
understand the motivation, since it seems reasonable to me that ferror()
should return EBADF after an attempt to read from stdout. At the moment,
ferror() returns 0 after an attempt to read from stdout.

Thanks,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: bin/12852: Non-standard behavior of fread(3)

1999-07-28 Thread Robert Nordier
Sheldon Hearn wrote:
 
 Could someone have a look at the patch proposed on PR 12852? I
 understand the motivation, since it seems reasonable to me that ferror()
 should return EBADF after an attempt to read from stdout. At the moment,
 ferror() returns 0 after an attempt to read from stdout.
 
There's no question this needs changing.  An ISO example actually
reads along the lines of:

while (!feof(fp)  !ferror(fp))
fscanf(fp, ...);

with no further provision for error-detection.  Applied to stdout,
this never terminates.

The SVID wording is more definite than ISO in discussing this (less
than nitems only if a read error or end-of-file is encountered),
but mostly the present behavior just conflicts with sense and
practice.

-- 
Robert Nordier


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message