Feature request for VS debugger

[dboggs]

I spend a lot of time fighting C strings--those character strings that have a null (CHAR(0) or ''C) following the useful part. Sometimes a null is needed and my string doesn't have it, either because of my carelessness or because of coded logic that was supposed to put it there and failed. Other times the null is there by accident and it shouldn't be. Debugging is harder than it should be because of the display format used by Visual Studio on watched variables: the nulls do not appear. For example, a CHARACTER(8) string of 'abcd'C appears as 'abcd    ', leaving me to my own methods to determine what may or may not be hiding in those last four characters.

How about displaying the string as 'abcd^   ', 'abcd^^^^', 'abcd####', etc. where ^ indicates a null and # indicates a blank, as the case may be? Obviously these may not be the best characters to use since they may have been used intentionally, but there should be some simple reasonable way around this.

My suggestion would be something similar to the option to toggle the display of numeric variables in either decimal or hex--i.e, a toggle to display character values in either "normal" or "special codes" where '^' represents a null, '#' represents a blank, and so on.

At least for me, this would save hours of debug time. 

[SergeyKostrov]

>>...Debugging is harder than it should be because of the display format used by Visual Studio on watched variables: >>the nulls do not appear. By definition 0x0 character is the end of a string and that was defined many-many years ago ( 40 or so ) in a C language standard. Even if you address that problem to Microsoft, since VS Debugger is designed and implemented there, I don't think VS Debugger will ever display a string content after the 0x0 character was detected. As a workaround you need to consider your own string-like type based on _int8 data type ( in that case it will be displayed as array of _int8 values ).

[Steven_L_Intel1]

It is not the definition of "end of string" in Fortran, and when debugging a Fortran program it should not be treated as such. I don't know how much control over this we have, though.

[dboggs]

Yes, of course I understand that a null is not treated as end of string in Fortran. The problem comes in when dealing with API functions--either in a Windows Project Type, or in a Quickwin Project where API functions may be called indirectly. Many of these require null-terminated string arguments. The best and simplest example is MESSAGEBOXQQ, but there are myriad others such as GetOpenFilename and GetSaveFilename. These can all be quite finicky to use because of the placement of nulls.

I am not asking for Intel to CONTROL this behavior, merely to add a display format option so we can easily see where the nulls are when debugging.

[Steven_L_Intel1]

I was responding to Sergey's comment....

We have an open escalated issue on this topic - the ID is DPD200013323. However, it's been open for a long time as it is deemed low priority.  I added your request to the list.

[dboggs]

Sorry Steve, I did not realize Sergy had responded. But note that his comment, "VS Debugger will ever display a string content after the [null] was detected", is wrong. VS will display the entire declared length of the string. Any embedded nulls simply show as blanks. This is not a helpful debugging feature when the issue you're struggling with is the proper use of nulls. In fact it is anti-helpful.

[Steven_L_Intel1]

Do you know about the memory view in the debugger? This will show you the exact bytes in a variable of any type.

[SergeyKostrov]

>>...but there are myriad others such as GetOpenFilename and GetSaveFilename. These can all be quite finicky to use >>because of the placement of nulls... I understood why you're interested in seening these kinds of strings and this is why: ... ZeroMemory( &ofn, sizeof( OPENFILENAME ) ); ofn.lStructSize = sizeof( OPENFILENAME ); ofn.hwndOwner = hWnd; ofn.lpstrFilter = RTU( "Windows AVI\0*.avi\0\0" ); ... I could do a verification with several VSs and since I have 8 ( from 4.x up to 2012 ) different versions which one are you interested the most?

[nvaneck]

Steve, what is memory view? I know about hexadecimal.  I often want to see the exact bytes of a buffer string variable which contains various types of values, but hexadecimal does no good with character strings.

[Steven_L_Intel1]

While in the debugger, select Debug > Windows > Memory > Memory 1. (Or just press Alt-6). The memory view will come up. In the Address field, just type the name of your variable. You'll see the memory in hexadecimal bytes and characters.

If the Watch window is indeed showing you all the characters, just without an indication of non-prinbtables, that is an improvement over what it used to do.  I will have to check this out.

[Steven_L_Intel1]

I just did a test - the debugger shows blanks for the remainder of the string after a NUL is seen, even if there are printable characters. So nothing has changed here.

You can view the contents of all the bytes of the variable in the VS2010 (and probably 2008) debugger's memory view window. For some reason, this doesn't work in VS2012 - I will report that to the developers.

[SergeyKostrov]

>>...I just did a test - the debugger shows blanks for the remainder of the string after a NUL is seen, even if there are printable >>characters. So nothing has changed here... I did a similar verification and if there is initialization of some string variable, like: ... ofn.lpstrFilter = RTU( "Windows AVI\0*.avi\0\0" ); ... then in a Visual Studio the Variable Watch displays "Windows AVI" and doesn't display "*.avi" ( after 1st '0x0' character ). Text, XML and HTML Visualizers also display a string until 1st '0x0' character, that is, "Windows AVI". If a variable name 'ofn.lpstrFilter' is dropped into a Memory Window all the rest parts of the string could be seen. Take into account that the Memory Window has a set of properties and my default settings are as follows: 1-byte Integer Hexdecimal Display Unicode Text

[SergeyKostrov]

One more thing, as a workaround you could try to use '|' characters instead of '0x0' characters, like: ... TCHAR g_szImgFilter[] = _T("Image Files (*.img;*.raw)|*.img;*.raw|AllFiles(*.*)|"); TCHAR g_szModFilter[] = _T("Input Models (*.dat)|*.dat|AllFiles(*.*)|*.*|"); ...

[Steven_L_Intel1]

I know it's been a while, but the developers have finally come up with a solution to this.

First, if a character value contains embedded NULs, these will display as a placeholder character as do other nonprinting characters. Second, if you try to modify the value in the debug window, you won't be able to change the NUL or anything after that. You can always open the variable in the Memory window and edit individual bytes there.

This solution will appear in a future product update (probably Update 3.)

[dboggs]

Thanks for keeping after this Steve.