(In reply to comment #0)
> At the least, they need to output a warning message that says something like
> "Config couldn't match the string XXX to an (attribute|trace source)".  These
> kind of output messages are enabled only if logging is enabled; it'd be nice to
> have the messages that indicate a failure to be output unconditionally.

The whole system works under the assumption that matching failures are not
errors: it is impossible to tell the difference between a match failure due to
a user typo or misunderstanding and a match failure due to the fact that the
user requested a different trace source than the one present in a specific
object.

So, the bottomline is that yes, the current system makes it hard to debug match
failures but there is no simple solution to that problem which does not suck. 

What is needed is something which returns a user-understandable report about
what matched, what did not match and why and the debugging output is none of
that. The hardest part here is first defining precisely the output you want to
get. Implementing the error report generation is not especially hard once we
have defined that.

(In reply to comment #1)
If a match fails on a certain string, the user should be notified of that.  A
failure is a failure...it is then up to the user to then debug and figure out
the WHY (does he misunderstand the path, is it a typo, is he asking for wrong
attribute/trace source, etc).  I see them as two separate issues.

I think this kind of alert would be very useful to our users.  But, if you are
suggesting deferring any such simple alert until a time when we have some kind
of more generic reporting system in place, then that is fine by me.

(In reply to comment #2)
> (In reply to comment #1)
> If a match fails on a certain string, the user should be notified of that.  A
> failure is a failure...it is then up to the user to then debug and figure out
> the WHY (does he misunderstand the path, is it a typo, is he asking for wrong
> attribute/trace source, etc).  I see them as two separate issues.

No, really, you have to understand that, from the point of view of the code,
failing to match "/NodeList/0/DeviceList/0/TxQueue" against a WifiNetDevice
instance because it does not have a TxQueue is just the same as failing to have
the same string with a typo match against a CsmaNetDevice because of the typo.
In the simple case where the user has not used wildcards, yes, one is obviously
an error and the other is not. 

But, if the user has used wildcards and a mixed network (wired + wifi), then,
the code has no way to know the difference between a match failure against a
non-existent and correctly spelled attribute (which is _not_ an error when
using wildcards) and a match failure against an existent but incorrectly
spelled attribute.

> But, if the user has used wildcards and a mixed network (wired + wifi), then,
> the code has no way to know the difference between a match failure against a
> non-existent and correctly spelled attribute (which is _not_ an error when
> using wildcards) and a match failure against an existent but incorrectly
> spelled attribute.

I should have pointed out that this kind of problem is pretty common: regular
expression matching suffers from the same problem: when you have a regex, the
regex engine cannot tell which matching failures are errors from the point of
view of the user and which are not. If there is a good regex debugging tool, I
am not aware of its existence but, I would love to see one...

should this be marked WONTFIX?  There are the Failsafe variants available if
programmers want to enforce the match.

(In reply to comment #5)
> should this be marked WONTFIX?  There are the Failsafe variants available if
> programmers want to enforce the match.
> 

The issue was with the Config::Connect* APIs, for which, from my understanding,
there are no failsafe versions.

To move forward, how about we deal with the simple case of Connect calls in
which there are no wildcards; if one of these doesn't match a trace-source, a
simple warning on the command line would be useful.

this bug is superseded by bug 284

*** This bug has been marked as a duplicate of bug 284 ***