Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] Patch to improve error messages


> >I've tried that for lots of patches through the years. I'm trying something > >a bit different this time to see if I have any better luck. It's an experiment
>  >if you will.
>
>  I'm not sure you're going to have much success
>  since ultimately someone should be opening a
>  bugzilla report. All you're doing is making more work for committers
>
>  Interestingly, you didn't supply the key piece of
>  information I requested. Reproducibility steps.

I understand from the above that you agree that it has been determined
that this is broken by inspection(and some cursory testing).

Surely it's not necessary to reproducability steps any more than
e.g. fresh regression testing cases for code that it is agreed is
broken by inspection?

I'll open a bugzilla report for this problem if there is consensus that
this should be fixed and that it can be agreed upon that it is broken.

In terms of testcase/reproducability, I'd go for a JUnit(or equivalent) test
for something like this. I don't know how to formulate such a test.

I very rarely change code based purely on inspection. I like to see something fail before I go fix it, especially if it's something reported by someone else...even if it looks obvious. I'm assuming you found this not by code inspection by actually seeing a nondescript error message surface. If you did, and it can be reproduced with a standard gdb/mi session, telling me what those steps are will make things easier for me. Otherwise, I have to go rig the code to manufacture the scenario I think you're having.

John


Back to the top