Sam writes:
> On Thu, 24 Feb 2000, Len Budney wrote:
> > 1. In my benchmark, I ganged 1,390 runs using actual, distinct email
>
> If you can't be bothered to properly interpret the results of the write()
> system call,
He *is* properly interpreting the results. He's just making the
interpretation easier by restricting the set of possible results.
> > 3. If you're making claims for putc(), why didn't your non-safecat program
> > _use_ putc?
>
> Free clue: read the putc macro yourself:
Sorry, no. You're not looking at *the* putc macro; you're looking at
*a* putc macro. One implementation need not resemble another at all
except insofar as they both exhibit certain externally visible
behavior. It doesn't even have to be a macro.
> > Why did you need to ``emulate putc()'s implementation
> > as closely as possible''? If you really did need to, why were you so
> > dismally incapable of it?
>
> Because, unlike you, I've actually read the headers,
No. You haven't read *the* headers. You've read *your* headers.
Anything you read in headers is not portable. Don't expect it to
apply to any other kind of system. Don't expect it to come into
consideration when dealing with portable software.
Even having read your headers, you aren't at all constrained to
emulate putc. If you really want an accurate picture of putc, use
putc itself, rather than guessing, correctly or not, at how a compiler
might optimize it.
> Last time I checked, a clock tick is 1/100th of a second.
This is also nonportable, and it's not even true on your own system.
Obviously, you've never checked at all.
#include <stdio.h>
#include <time.h>
int main(void) {
printf("%f\n", (double)CLOCKS_PER_SEC);
return 0;
}
Or did you mean hardware clock ticks? Does your processor run at
100Hz (that's Hz, not MHz)? I thought not.
> > > > How do I know why putc() fails when it fails?
> > >
> > > Check errno. Always works for me.
> >
> > This is guaranteed on which platforms?
>
> POSIX-compliant ones.
This is just a misunderstanding, I think: I believe the failure Len
was referring to is the failure resulting from a signal, which you
agreed would have bad effects on stdio.
paul
