#include <stdio.h>
int main()
{
int code;
printf("Entyer the error code (1-3): ");
scanf("%d",code);
switch(code)
{
case 1:
puts("Drive Fault, not your fault.");
break;
case 2:
puts("Illegal format, call a lawyer.");
break;
case 3:
puts("Bad filename, spank it.");
break;
default:
puts("That's not a 1, 2 or 3");
}
return 0;
}
Well listing to your compiler might help, you should be getting at least a couple of warnings.
1 2 3
8:20: warning: format '%d' expects argument of type 'int*', but argument 2 has type 'int' [-Wformat=]
8:21: warning: 'code' is used uninitialized in this function [-Wuninitialized]
Sequence of Events
1 - F9 to Build & Run
2 - Enter a value as requested
3 - Presneted with 'file.exe has stopped working' dialog with 'Debug' or 'Close Program' options
3 - Click on 'Close Prgram'
4 - .exe window still open with Message of - Process returned 255 (0XFF) execution time : 62.523 s Press any key to continue
5 - Press a key and the .exe window closes return the log below
-------------- Run: Release in ex0817 (compiler: GNU GCC Compiler)---------------
Checking for existence: C:\Users\Rousseau Associates\Documents\Code Blocks\Test Projects\Learning\ex0817\bin\Release\ex0817.exe
Executing: "C:\Program Files (x86)\CodeBlocks/cb_console_runner.exe" "C:\Users\Rousseau Associates\Documents\Code Blocks\Test Projects\Learning\ex0817\bin\Release\ex0817.exe" (in C:\Users\Rousseau Associates\Documents\Code Blocks\Test Projects\Learning\ex0817\.)
Process terminated with status 255 (0 minute(s), 20 second(s))
Guys, this is a run time issue. The code isn't going to be what is causing this.
OP wrote:
When I am running code in Code Blocks ... Visual Studio Just-in-time Debugger
My bet is that you are using the default setup for Code::Blocks meaning that you're compiling the code in MingW against its own version of the standard library (which is out of date btw). But when you are running it, it is linking to the version in your system32 folder which I'll bet is the one for Visual Studio or just some other version. Find each of the msvcrt.dll files, the one in system32 and the one in the mingw folder for the C::B installation, then "right click" -> "Properties" -> "Details" tab to compare the version numbers. If you really wanted to confirm this, you can use Process Explorer from SysInternals to actually look at which of the dlls gets loaded into your application: https://technet.microsoft.com/en-us/sysinternals/processexplorer .
I have a feeling I did something before this started to happen that may have made some changes. Not sure how but I recall something I'd not seen before popping up and I think I just clicked OK.
Anyway, I will have a go at you suggestions but being new to this I may need a bit more direction if that's OK.
Also, with what you are suggesting, has it the potential to 'break' anything? I wouldn't want to make changes that could make the problem worse?
Also, with what you are suggesting, has it the potential to 'break' anything?
Everything that I've described is a read only operation, so no, not if you only do what I have written. We're verifying my theory, not flailing around blind trying to implement an uninformed fix. I could be wrong, in which case we have to go in a different direction.
I have used the text from the tutorial as written so what should this be written as?
I have used it in the same way for quite a few tutorials prior to the one I experienced the issue with so is there any reason why I wouldn't experience the issue on the first use of this?
You're missing an ampersand from Line 8: scanf("%d",&code);
EDIT: This still doesn't explain why the code that you said worked fine before is suddenly breaking now. Unless the tutorial you are using has mistakes like these all over the place, which is very possible with this language. Link?
EDIT: This still doesn't explain why the code that you said worked fine before is suddenly breaking now. Unless the tutorial you are using has mistakes like these all over the place, which is very possible with this language. Link?
Actually it does. Undefined Behavior is a very strange bedfellow, it could work for days, weeks or even years as you expect, then out of the blue it could crash spectacularly. A small change in the program layout, slightly different compile options, almost anything can be the straw that breaks the camels back.
You should always suspect your program is the cause of the problems, problems with your tools will be very very rare unless you are trying to use the newest aspects of the language.
Which is why I asked for a link to the tutorial site, to confirm that the author of the site is indeed an idiot. You're probably right, I'm just putting too much faith in people who write tutorials being able to code properly.
Erm ... The '@' character isn't a valid operator character in C or C++, and I'm not sure where you got the impression that we were talking about that. I know this for a fact because it's actually the thing that bothers me the most about both of these languages because it would make SO MUCH MORE SENSE to use "at" instead of "and" when referring to the address of a variable.