shame on Microsoft failing to fix simple bugs

Eugene

table 381
in NAV3.0 we had

IF STRLEN(t) + STRLEN(Format) + 2 <= 250 THEN
        t := t + ', ' + Format
      ELSE
        t := t +'...';

sometimes this code would cause Text overflow on line t := t + '...'
what was the MS bugfix for this ? - in version NAV5.0 we have:

IF STRLEN(t) + STRLEN(Format) + 5 <= MAXSTRLEN(t) THEN
        t := t + ', ' + Format
      ELSE
        t := t +'...';

i don't know what kind of people Microsoft hires for the bugfixing but i think even a schoolboy would not fail to fix it

matttrax

Funny article I was reading yesterday about how 90% of programming job applicants can't program.

http://www.codinghorror.com/blog/2010/0 ... ammer.html

For those who don't see it right away, there are a couple of problems with this. One, it hard codes the number 5, essentially chopping off characters from the result string. Two, if the string reaches the point where '...' is added, and the function is called again it will error out.

Here's some sample code to test for yourself:

FOR i := 1 TO MAXSTRLEN(t) DO BEGIN
  toAdd := FORMAT(i MOD 10);
  IF STRLEN(t) + STRLEN(toAdd) + 5 <= MAXSTRLEN(t) THEN
    t := t + ', ' + toAdd
  ELSE
    t := t +'...';
  IF CONFIRM('%1', TRUE, t) THEN;
END;

t is a Text of length 10
toAdd is a Text of length 1

Where the code would ideally stop adding to the string it just continues. Something like this might have been more appropriate:

FOR i := 1 TO 4 DO BEGIN
  toAdd := FORMAT(i MOD 10);
  IF STRLEN(t + toAdd + ',' + '...') <= MAXSTRLEN(t) THEN
    t := t + ', ' + toAdd
  ELSE IF STRLEN(t + '...') <= MAXSTRLEN(t) THEN
    t := t +'...';
  IF CONFIRM('%1', TRUE, t) THEN;
END;

There are test cases like whether or not the concatenation of the strings matches the exact maximum length or if it matches the maximum length and there are still more elements (in which case a ... should be displayed instead of the element because there wouldn't be room for the ... after the element is added).

*sigh* I'm such a nerd :shock:

Alex_Chow

V3 is not supported anymore, so I doubt MSFT will bother taking the time to look.

If it was a bug when V3 was still under support, then no partner reported it as a bug. Or they just fixed the problem in version v3.1, 3.6, or later.

matttrax

Point is that the bug still exists in V5. It was "fixed".

Alex_Chow

matttrax wrote:

Point is that the bug still exists in V5. It was "fixed".

You're right... I didn't read the whole post... :oops:

kine

You know, many "trivial" bugs are still there because everybody who hitted them, corrected them on their own and they didn't report it, because "I am sure that somebody else already reported it"... 8)

matttrax

kine wrote:

You know, many "trivial" bugs are still there because everybody who hitted them, corrected them on their own and they didn't report it, because "I am sure that somebody else already reported it"... 8)

Wouldn't surprise me at all. This one probably doesn't occur too often and even looking at the code is easy to overlook.

idiot

I would not call this a bug.
The system is just not designed for
STRLEN(t) + STRLEN(Format) + 2 > 250 in 3.0 and
STRLEN(t) + STRLEN(Format) + 5 > MAXSTRLEN(t) in 5.0

Sometimes when you're allowed to do something it doesn't really mean it should be done.
Remember that Nav is belonged to the previous era

matttrax

idiot wrote:

I would not call this a bug.

How can you call an overflow error that could easily be coded for not a bug?

idiot wrote:

The system is just not designed for

But that's exactly what they were trying to design for. They wanted to put a "..." at the end of the string when it couldn't fit anymore characters. They obviously expected to get large strings at some point.