Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Changes in STRNCMP

Asked by Jan Simon on 29 Sep 2011

When did STRNCMP change its behaviour?

Matlab 2009a:

    strncmp('asd', 'qwe', 0)   % >> 0

Matlab 2011b:

    strncmp('asd', 'qwe', 0)   % >> 1

 

And in general: What is an efficient way to determine the release, when a function was changed?

 

[EDITED] 30-Sep-2011, 06:48 UTC

Matlab 2009a:

strncmp('a', 'a', 2)   % >> 0

Matlab 2011b:

strncmp('a', 'a', 2)   % >> 1

There are good arguments for the one and the other reply. But there are no good arguments for changing the behaviour of such elementary functions. It affects about 40.000 lines of my code, which directly and indirectly depends on the replied values.

I'm trying to migrate from 2009a to 2011b and this first problem stopped the tests after 3 minutes only. And there is no really convenient way to find a description when and why STRNCMP has changed. Even the bug-report is misleading:

 STRNCMP and STRNCMPI return FALSE when comparing cell arrays and
 considering 0 characters (i.e., with the third input set to zero).

No, it does not concern only cell arrays, but CHAR vectors also.

3 Comments

bym on 30 Sep 2011

as a tangent: in what situation would you use strncmp('asd', 'qwe', 0)?

Walter Roberson on 30 Sep 2011

longest prefix matching?

Jan Simon on 30 Sep 2011

@proecsm: I'm using a large software package with >300'000 lines of code (plus comments!). Such packages cannot be controlled manually anymore, such that automatic tests are needed to check the compatibility. To compare the functionality of my function STRNCMPR (compare strings from the right, FEX) I compare it with the builtin STRCMP with flipped inputs. Besides the known answers tests I use a gun-shot-programming technique to check the reaction of the function to wrong and "almost wrong" inputs. In the case of STRNCMPR this means feeding with cells of numerical arrays, multi-dimensional empty cells, cells containing NULL pointers, and N set to Inf, -Inf, NaN, [], -1, uint8(N), NULL pointer, and of course 0.
Now the unit-test fails, because STRNCMP has changed. In consequence all tools, which are using STRNCMP and my STRNCMPR are marked as invalid. "Well, I hope it will run inspite of this, 0 length comparisons are so unlikely" is not a reliable reaction, because the tool is used for clinical decision making, which urgently requires a standardized quality control.

Let me mention, that this let me react more emotionally, than I want to express in this public forum.

Jan Simon

Products

No products are associated with this question.

3 Answers

Answer by Wayne King on 29 Sep 2011
Accepted answer

Hi Jan, This was a bug fixed in R2010b

http://www.mathworks.com/support/bugreports/629110

Hope that helps, Wayne

6 Comments

Jan Simon on 7 Oct 2011

TMW might estimate, that the former behaviour was not a severe bug. But changing the behaviour of STRNCMP in two details causes severe bugs in my programs. Therefore I'm convinced, that changing the behaviour of fundamental function must follow these rules:
1. Avoid them, because even "not severe" changes will cause severe bugs in many user-land programs.
If not possible:
2. Document them explicitely in the release notes, help text and list of changes.
3. Document them even more.
4. Test all possible side-effects hysterically.

It seems to me, as the questionable reply of "strncmp('a', 'b', 0)" was changed for some reasons, but this introduced the behaviour "strncmp('a', 'a', 2)==TRUE" as bug, which has not been detected due to weak or missing unit-tests.
Such "actually unimportant" and in consequence undocumented changes discourage users from migrating to a new Matlab release. It is not easy to control the quality of a Matlab program when migrating without knowing the methods and results of the quality control applied to maintain Matlab itself.

Yair Altman on 29 Oct 2011

@Andreas - most of the respectable software vendors that I know are not ashamed in listing bug fixes when they release new versions, even if the bugs were discovered internally as in this case.

Jan's example is simply one case of many. When I upgrade my clients' software to a new release I depend on the release notes to give me an accurate description of all the changes, so that I could make an informed decision about what to check and possibly fix for the new release. If MathWorks chooses to hide this information from users then I cannot make informed decisions!

I am sorry to say that I am very disappointed with MathWorks for this.

MathWorks reportedly places huge efforts in backward compatibility, and changing things like this, *AND THEN NOT EVEN REPORTING THEM!*, makes a mockery of such efforts.

Andreas Goser on 15 Nov 2011

I respect and understand your viewpoint and will forward it to the right person. For now, the FAQ for Bug Reports http://www.mathworks.com/support/faq/bugreportsfaq.html mentions: "6.Why aren't all bugs shown? Why isn't the bug I reported showing up? Bugs reported in this system are those that may be of interest to customers, based on general use of our products. Bugs are updated by the development team as more information and releases become available. This includes provisions for any known workarounds or file replacements. Bug report information is available for bugs either exist in or have been fixed in Release 14 SP2 or later. Information is not available for all bugs, known or unknown, including bugs in prior releases. If you feel your bug should appear in this table, contact technical support and ask that your bug be nominated as a bug report."

Wayne King
Answer by Kelly Kearney on 7 Oct 2011

On the topic of history, I've requested this as an enhancement multiple times. When I wrote to the Mathworks to ask whether I could get a complete change history of a particular function (in my case, minor updates to datetick that hadn't made the release notes were affecting my code), I was told that the best way to check this was to look at the Revision line in the m-file itself.

Of course, this is only possible if you actually own all releases. I don't, but the Mathworks of does. Assuming they don't already have a centralized database of change histories for all functions, it seems to me it would be a relatively simple endeavor to write a simple file parser that reads out the revision line from each function in each release. Then users could get a clear idea of when each function was introduced, when others were phased out, and when both major and minor changes were made.

1 Comment

Jan Simon on 7 Oct 2011

I really agree. I need a database which contain:
1. A list of the names of toolbox functions (to avoid collisions, e.g. if I share a function with another lab, which uses more toolboxes than I do).
2. The time-history of this list, such that I can if the other lab running Matlab RXYZ can use STRREAD, REGEXP('split') or TEXTSCAN.
3. A list of changes in the behaviour.

While 1. and 2. could be solved by a tiny program and the collaboration of 20 or 30 other contributors, point 3. should be created by TMW. It would be a silly idea to create an undocumented documentation.
Digging in the release notes is not efficient or complete enough to be an alternative.

Kelly Kearney
Answer by Walter Roberson on 29 Sep 2011

I don't know when the functionality changed, but I observe that the documentation of strncmp and strncmpi were split as of 2011a. The merged 2010b page vs split 2011a page

The only "efficient" way I have found to identify changes is to request searching an older release, and then edit the URL to move between different versions. :(

I'll be looking through the beta Documentation Center

2 Comments

Walter Roberson on 29 Sep 2011

Darn. Beta version doesn't give any change history either, and also doesn't have that link near the top to the launchpad for searching specific releases.

Walter Roberson on 29 Sep 2011

http://www.mathworks.com/help/matlab/ref/strncmp.html

is the beta page.

Walter Roberson

Contact us