LabWindows/CVI Idea Exchange

Hello,

• Right now, the Break on»Library Errors function break happens for all library errors. I would like to suggest a more granular setting, i.e. break on file I/O errors, math errors, etc.

• An additional (and most relevant) feature I suggest is the option to allow to temporarily exclude certain errors; let's say I have a loop doing some calculations and these calculations result in an ERANGE error, then it would be useful to get notified by the debugger, but only once for this loop, not 500 times... Hence after a break on library error I would like to have the (right click) option 'exclude further breaks of this function'. This should be valid for the current execution and be automatically reset when the program is restarted.

• Also, the menu command should provide the possibility to override all SetBreakOnLibraryError functions.

Many thanks!

The JIT debugger option in CVI 2010 is a nice step in the right direction, but only being able to debug builds that were compiled in "Debug" mode pretty much defeats the whole purpose of the idea. Debug builds are much too slow to be used in production and on my machines, if I ever use a Debug build, it probably already runs under the debugger anyway! Seeing that CVI is not even an optimizing compiler I cannot understand why release builds cannot be properly debugged. 

Thing is, the crashes in production are the important ones that I absolutely need to be able to investigate, and CVI does not provide ANY assistance in this area apart from being able to at least generate a MAP file. This is what I currently have to do: I have included code in my application that creates a memory dump and sends it to me when the application crashes or hangs. This dump I can then load into WinDbg and with a few tricks I can at least import the CVI MAP file to get some functions names in the stack traces, but that's it, all investigations have to be done on the assembly level. To quickly decipher stack frames, e.g. to have a look at local variables, I often even have to throw my OWN code into a disassembler (IDA Pro)! I'm really glad that this way I am now at least able to debug most crashes at all, even when they happen far away in a different country, but this aren't the 80s anymore and you can probably imagine that this process is hard and time consuming and very much annyoing. With code compiled in VC on the other hand I can load a MiniDump and have a look at the stack trace, variables and code on the source level without much hassles. 

Some ideas that could help:

 - Let me (JIT) debug release builds

 - Let me load MiniDumps into the debugger or

 - create PDB files that I can use together with a debugger that can load MiniDumps (WinDbg, VS)

 - Let me not only use an external compiler but also an external linker that generates PDB files for release builds (I don't like this solution as I use C99 features VC does not support, but I'm desperate here)

Okay, rant over for now, I think I really needed to vent a bit. Thanks for reading this far ;-) 

All the best, Marcel 

well, the title says it all: extend the current partial support of C99 standard to full support

Hi,

I would like to see an configuration of batchbuilt process. I have a big workspace with many projects; and would like to create different setups, like "compile only all server projects" or "compile all client projects". The workspace contains a big server-client -based software packages; some dll-projects used for server side only, some only client side.

Peter

Greetings,

LabWindows/CVI 9.0.1's implementation of <stdio.h> *scanf and <stdlib.h> strtod functions appears not to support reading back "NaN", "Inf", "+Inf" or "-Inf" values, although printf() can generate them. May I suggest to add functionality like described below.

Practical use would be that it's easier to propagate "invalid measurement" through strings if strto*() and *scanf() understand all classes of strings that *printf() family functions will generate.

This suggestion is in alignment with ISO 9899:1999 (withdrawn) and its successor ISO 9899:2011, i. e. C99 and C11. Note that there is a "stronger" suggestion to implement all of the C11 standard library in the idea exchange already, which - if implemented - would subsume this suggestion, but as the bare minimum, I'd certainly appreciate seeing this in CVI 2012.

Demo code:

 printf("%g\n", -NotANumber());
 printf("%+g\n", PositiveInfinity());
 printf("%g\n", NegativeInfinity());
 double x = 0; int i;
 i = sscanf("NaN", "%lf", &x); printf("i=%d, x=%g\n", i, x);
 i = sscanf("Inf", "%lf", &x); printf("i=%d, x=%g\n", i, x);
 errno = 0; x = strtod("NaN", NULL); printf("x=%g, errno=%d\n", x, errno);

Desired result:

 -NaN

 +Inf

 -Inf

 i=1, x=NaN

 i=1, x=Inf

 x=NaN, errno=0

Actual result: we see that printf supports NaN/Inf, but scanf and strtod do not:

 NaN
 +Inf
 -Inf
 i=0, x=0
 i=0, x=0
 x=0, errno=0

Thank you.

I'd really appreciate a warning for "empty bodies" or whatever it is called, i.e. things like

for(...);
while(...);
if(...);

 If written like

if(...) { };

 it is OK.