Errors in user input should detected where user input is parsed. This
includes checks that pre-conditions for internal API calls are
satisfied.
Internal functions should use an assert.
Moving user error diagnostics from the user input functions to
internal functions is a clear violation of the AP
I'm satisfied that I've put the performance issue with checking at too
low a level on the radar.
I'll leave this to Zach's judgement (he's the one who's working on it
currently), but I'm reserving the right to raise an objection later based
on measured performance problems(referring to Rick pointi
On Monday 08 June 2009, Zach Welch wrote:
> Basically, the JTAG library should not make policy to abort, if it will
> be used by script commands.
Right, it should not be possible for anything done by a client
to cause the server to crash.
___
Openocd-de
On Jun 8, 2009, at 11:51 PM, Øyvind Harboe wrote:
On Tue, Jun 9, 2009 at 8:29 AM, Zach Welch
wrote:
On Tue, 2009-06-09 at 07:57 +0200, Øyvind Harboe wrote:
How about a clearer policy of using assert()'s?
I'm thinking that error()'s should be reserved for "real" runtime
errors.
jtag_add_pathmove() is not a high performance API, so here
runtime (debugging or otherwise) checks do not really affect
anything much.
A better example would be jtag_add_dr_out(). Here I don't want
lots of runtime checks as this is used in the innermost loops. All
checks on userdata must happen hi
On Tue, 2009-06-09 at 08:51 +0200, Øyvind Harboe wrote:
> On Tue, Jun 9, 2009 at 8:29 AM, Zach Welch wrote:
> > On Tue, 2009-06-09 at 07:57 +0200, Øyvind Harboe wrote:
> >> How about a clearer policy of using assert()'s?
> >>
> >> I'm thinking that error()'s should be reserved for "real" runtime er
On Tue, Jun 9, 2009 at 8:29 AM, Zach Welch wrote:
> On Tue, 2009-06-09 at 07:57 +0200, Øyvind Harboe wrote:
>> How about a clearer policy of using assert()'s?
>>
>> I'm thinking that error()'s should be reserved for "real" runtime errors.
>>
>>
>> > if (!tap_is_state_stable(path[num_states -
On Tue, 2009-06-09 at 07:57 +0200, Øyvind Harboe wrote:
> How about a clearer policy of using assert()'s?
>
> I'm thinking that error()'s should be reserved for "real" runtime errors.
>
>
> >if (!tap_is_state_stable(path[num_states - 1]))
> >{
> >LOG_ERROR("BUG: T
How about a clearer policy of using assert()'s?
I'm thinking that error()'s should be reserved for "real" runtime errors.
> if (!tap_is_state_stable(path[num_states - 1]))
> {
> LOG_ERROR("BUG: TAP path doesn't finish in a stable state");
> - exit(-1);
