visual c++ 2010: "step into" steps into C functions problem

Hi all.

I've got an unsolvable problem with Code:Blocks(for Windows, Linux version works fine), so am switching to VC++ 2010 Express.

Anyway, the problem now with VC is that when I click "Step Into", it steps into C functions like printf(). How can I just step through my own code only?

I've tried to sign up 3 times to the Microsoft forums to ask, but it simply will not let me log in with my username/password.

From my 15 minutes of googling, I think that I might need to edit the registry, which I am not really comfortable with doing. I am hoping that someone here knows of a setting somewhere in VC that I can turn on or off to fix the problem.

Thanks in advance.

Don't click "Step Into" when you're at a printf call. Click "Step Over", or the equivalent.

Alternatively, there is probably a way to link against the non-debugging version of the standard C library (I think MS calls it the run-time library, or mscvrt.dll or some such). Such a version would have no debugging symbols or info, so you the "step into" button might just "step over" the standard function calls. That's just a guess though. Unfortunately, I'm a Linux guy, so that's the extent of my knowledge.

The debugger in VS will not step into functions that don't have source code, unless you switch to the disassembly view and step directly into the CALL instruction.

Get used to keeping two fingers on F10 and F11 and pressing the correct key for what you want to do. If you accidentally step into something, you can step out with Shift-F11.

Thanks for the replies.

Step Over did the trick. In Code::Blocks, I had never ever used Step Over when debugging, since it only steps into my own functions(which is what I want). In VS, it looks like I will be using Step Over for about 97% of the time(since 97% of the functions in my programs are C library functions). Two different ways of getting the same result. :D

VS gives a lot of warnings about unsafe functions. GCC never had such warnings, even when I turned pedantic warnings on. VS is gonna take some getting use to. :D

Code:

---

main.c(50): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
main.c(89): warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead.

---

> use _CRT_SECURE_NO_WARNINGS.
Perhaps you could google the last part of your error message.
It tells you how to turn off all the pointless M$ nagware and vendor lock-in traps.

> main.c(89): warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead.
The problem with all this nonsense is that they're only SAFE if you know how to use them properly.
Which is exactly true of the original functions.
If "noob in a hurry" just passes useless "STFU" parameters to strncpy_s, then it's just as dangerous as strncpy is.

Code:

---

errno_t strncpy_s(
  char *strDest,
  size_t numberOfElements,
  const char *strSource,
  size_t count
);
...
char buff[10];
strncpy_s(buff,sizeof(buff),"hello world",10);  // ok, but truncated string

---

So some dimwit comes along and tries to "fix" it by doing

Code:

---

strncpy_s(buff,100,"hello world",10);  // yay!, I see the whole string

---

It's a small enough buffer overrun to potentially go unnoticed for quite some time.

All the warm fuzzy feel good of the _s functions won't do you any good at all if you don't know how to use them properly to begin with.

Quote:

---

Originally Posted by Salem

It tells you how to turn off all the pointless M$ nagware and vendor lock-in traps.

---

The C standard is a vendor lock-in? You are aware those _s functions are a part of C11, right?

Interesting adeyblue, I had thought Microsoft had abandoned any interest in C when they decided not to support C99.

Still, gotta wait some while before a range of C11 compilers are available before it could be called portable.

Quote:

---

It now is part of C11 as the (optional) Annex K

---

Somehow, I can't keep my eyes off the optional.

Quote:

---

Originally Posted by Salem

> main.c(89): warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead.
The problem with all this nonsense is that they're only SAFE if you know how to use them properly.
Which is exactly true of the original functions.
If "noob in a hurry" just passes useless "STFU" parameters to strncpy_s, then it's just as dangerous as strncpy is.

All the warm fuzzy feel good of the _s functions won't do you any good at all if you don't know how to use them properly to begin with.

---

While this is true, Salem, remember that the non_s functions don't give the option to do any security checks at all, while the _s functions do, provided you use them correctly.
That is reason enough, IMHO, not to dismiss them outright.
Learn to know your tools. One of THE most important lessons in C (and C++).