This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug tapsets/2861] user_string fault handling


On 29 Jun 2006 01:08:46 -0000, fche at redhat dot com
<sourceware-bugzilla@sourceware.org> wrote:

------- Additional Comments From fche at redhat dot com 2006-06-29 01:08 ------- > Is there really a need for a caller-specified error message that would > justify the overhead of the extra strcpy?

Yes, as a style matter, in order to avoid setting arbitrary english strings as
values that may need to be further processed by script.

> I'd like to avoid changing all the current code.  How about
>
> user_string(addr) ==> returns "<unknown>" on error

shouldn't it return NULL or possibly -1 and then the script then request the exact error code as common with C programming?

James Dickens
uadmin.blogspot.com




This works okay only if the returned string is simply going to be passed straight to an english-speaking user, and not e.g. tested by the script for its own error-detection purposes. Plus it has no way of telling apart legal occurrences of the fixed string "<unknown>" from the error indication. In the absence of multiple return values and exceptions, letting the caller specify their favorite soft-error value seems to be he next best thing.

> user_string(addr, 0) ==> same as above but prints warning

The ", 0" setting is not helpful (nor is the "0" too informative).  We
don't print run-time warnings at the present, and for good reason: they
are only noise.

> user_string(addr, 1) ==> prints error message and sets lasterr

I don't find the ", 1" is too informative.


Nevertheless, I am not strongly attached to these options, so if others wish to voice support for hunt's suggestion, or offer new ones, please do.


--



http://sourceware.org/bugzilla/show_bug.cgi?id=2861


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]