Re: [htdig-dev] OS X 10.2

[Jim C. <gre...@yg...>]

Gilles Detillieux's bits of Fri, 6 Sep 2002 translated to:

>This is what I really hate about C++!  So many of the so-called standard
>classes aren't really that standard, and vary from one implementation to
>another, and one release to another.  How intuitive is this?  bad() is
>not to be taken as an antonym of good()?  If what you're saying is true,

No argument. The naming leaves a lot to be desired in this case.
Also the inconsistency in what the accessors do. eof() and bad()
check only eofbit and badbit, respectively. fail() checks failbit
*and* badbit (for historical purposes, according to a footnote).
good() essentially checks all three, ensuring that none are set.

>then 3.1.x's htlib/Configuration.cc code will also bomb if it can't open

Yes, it will ;) I just verified this with htnotify. However for
htnotify it is only an issue if -c is used, since configFile is
set to DEFAULT_CONFIG_FILE by default. From what I can tell, all
of the other programs are protected from this problem by a call
to access() (and then reportError() if access() fails), which
precedes the calls to Configuration::Read().

>the config file.  So, just how standard is the behaviour you describe?

Based on my experience, it is standard behavior; however I of
course won't claim that that experience covers the majority of
possible compiler/OS combinations. Inconsistency and naming
issues aside, the standard is crystal clear in terms of specified
behavior, so there is really no good excuse for a non-compliant
implementation.

>If we start using in.good() in htnotify.cc and Configuration.cc, instead
>of !in.bad(), will the code work correctly on all supported platforms,
>or will it start to bomb on some of the systems where !in.bad() used to
>work fine?  Do we need configure tests for all this nonsense?

I would argue that any compiler that is unable to handle such a
change is very much broken in this regard. For whatever it is
worth, my suggestion would be to add an access() call to htnotify
in the 3.1.x branch, as implemented in the other programs, and
then migrate from !bad() to good() in the 3.2.x branch. I think
the access() call will be enough to protect htnotify from an
invalid config file argument and at the same time minimize the
amount of code that needs to be touched. If there are any
platforms for which configure tests are needed, hopefully that
will get flushed out in the 3.2.x betas.

>but I can't find any information on what the distinction is between
>badbit and failbit.  Is this consistent across all platforms?  If so,

Again based on my own experience, it is consistent. As for the
distinction between the two bits, my understanding is that badbit
is used for cases where the stream encounters a problem so severe
that all bets are off; there is no reasonable recourse other than
abandoning the stream object altogether. On the other hand, the
failbit indicates that some sort of stream related failure
occurred, but that recovery is not out of the question; in most
cases it should be possible to clear the bit, put things back to
some known state, and then continue (e.g. clear the bits, call
ifstream's open using a different file name, and continue).

Jim