I'm working on an assignment and I'm pretty much done, but I've run into a roadblock. I'm trying to print out all the "emirp" numbers my program generates, but if I try to print after running my EMIRP finding loop, it causes a Debug Assertion Failed error with this message.
Here's the program source.
http://pastebin.com/f81rE4hb
I'm a C++ guy in transition to using C, so maybe it's a C-specific problem causing it. If you need an explanation of anything, just ask. I'm compiling this with Microsoft Visual Studio 2012 Professional.
In my case it had to do with mixing unicode main program with non unicode external library written in C. This is what helped to me. Before calling first printf in external library I had to change console mode to ansi. After external library call I had to set mode back to unicode:
#include <io.h>
#include <fcntl.h>
_setmode(_fileno(stdout), _O_TEXT);
....
_setmode(_fileno(stdout), _O_U16TEXT);
Your problem is that you do emirps++:
You won't be able to free the memory that you've initially allocated, since emirps no longer points to the beginning of that memory.
You most certainly can't go about passing emirps[i] to printf (or any other function for that matter) at that point.
BTW, just noticed that there's a "whole bunch of mallocs" in your code not being freed anywhere...
Related
i'm new to C programing and i was testing some code when i compiled it this error came up:
fatal error: 'conio.h' file not found #include <conio.h>
this was on the top of the code i was testing:
#include <stdio.h>
#include <conio.h>
...
i searched about this error but i only found answers related to windows and ubuntu
i'm running mac os
conio.h is not a standard library header, and the functions it declares are not standard library functions - it's specific to an ancient implementation that isn't used much anymore. If the code you're trying to build uses conio routines like getch(), then it won't build on a Mac.
It depends of what compiler are you using.
Conio.h is mostly header for MS-DOS compiler, so it can be unavailable in some others packages.
If you tried to use getch() as tool to stop console from closing after execution, simply replace it with scanf():
int a;
scanf(%d,a);
Console will close after pressing Enter
See here Conio is dead already do not use my friend I have noticed many YouTubers in initial coding use getch() to make your code wait for you to press a key and when pressed it is done but now conio isn't even a part of c/c++ it works in MS-DOS based compiler and turbo-c++ but most of the turbo c++ code turns out erroneous as they use old c/++ syntax that is deprecated a long back in the history of development in c/c++.
#include <conio.h>
Suggestion : Remove These lines and voila it works
Happy Coding!
I encountered the same situation. My xcode suggested #include <curses.h> instead. I changed accordingly, now it builds.
So this is my first post. I am preparing for some upcoming college courses on programming, one of them deals with C. I have been teaching myself for a little while and have never encountered this problem before, even though I have used the same code. I am having the issue on any ide that I use, which are MS Visual Studio 2019, and Codeblocks, both 16.01 and 17.12.
The problem is when I try to include an inline function, the compiler brings up an error: identifier "keep_window_open" is undefined, as well as the error: 'keep_window_open':identifier not found.
This never happened until I upgraded Codeblocks from 16.01 to 17.12, so that leads to believe something happened with the compiler or some settings that I don't know about, or how to change.
I have tried going back to Codeblocks 16.01, but still get the same error. All my previous programs, that use the exact same code still compile and run, so I am at a lost and completely frustrated. Enough so to think about changing my major, which I really do not want to do. I enjoy programming. But this problem is killing me.
#define _CRT_SECURE_NO_WARNINGS
#include<stdio.h>
inline void keep_window_open() { char ch; scanf("%s", ch); }
int main()
{
printf ("Lets see if this stupid thing works\n");
keep_Window_open();
return 0;
}
The problem is the line of code:
keep_Window_open();
If I comment it out, the program will compile and run, however I can't see it, because all it does is flash and then close the console window. And I need to use this code to see the output window. As I have said I have used this code in many other programs, most of which are much more complex than this, and they all still compile and run. It is only on new projects that I try to create.
I expect the window to stay open until the user presses and enters a key, like it always has before. I am stuck, and would appreciate some input on how to proceed, other than throw myself in front of a bus.
OK, so I was able to solve the issue in CodeBlocks, but not in Visual Studio. I changed the code to have the inline function below the main function, and now when compiled and run in CodeBlocks (17.12) it works exactly like it should, or how I thought it should.
However when I try the same solution in Visual Studio, after putting the inline function below the main function I now get a new error:
'keep_window_open' redefinition basic types
Since I usually use CodeBlocks for C, Visual Studio for C++ and intellij for java, I am not going to worry about this, as long as it works in CodeBlocks I should be OK. However I am curious as to why it work in one IDE and not the other?
I am new to this programming thing, and there is much to learn, and I know virtually nothing about compilers and linkers, as I am focusing on programming techniques and syntax in several different languages.
I wanted to show my students how to use regular expresions. As they are learn programming in C, I thought it would be the best to use regex.h from GnuWin32 (http://gnuwin32.sourceforge.net/packages/regex.htm). As an example I tried to run http://www.peope.net/old/regex.html programm, but it causes an exception on the variable holding the regular expression at runtime . The precise error message is:
Run-Time Check Failure #2 – Stack around the variable 'regex' was corrupted
The courius thing is that the example itself is running properly and the regex functions seems to work properly. The error happens after all the important things are over at the point where main() wants to return.
Has anybody an idea of why this error occurs? Could the 64-Bit System I'm using be part of the problem?
Thanks for any advice!
I am trying to debug the following C code with eclipse-Juno-CDT, and cygwin-gcc (cygwin version=1.7.16, gcc version=3.4.4, gdb version=7.5.50), on 64bit windows. The code works fine in normal mode. Initially debugger was not running, because the source file was not found. Then I searched around and added the path mapping information (from /cygdrive/c to C:\). Now it is running but with the following problems:
I have put a breakpoint before the "hello c 1" line, and then single stepping. But nothing gets printed on the console.
after single stepping on the last line ("exit"), I get the error: "No source available for _cygwin_exit_return() at ..."
// stdio.h and stdlib.h are included, but when I put a #include the code
// they dont show up, so I deleted those lines in this code fragment.
int main(void) {
int a=10;
int b=5; // breakpoint on this line, single step after this
printf("hello c 1\n"); // these outputs are not printed in console
// fflush(stdout);
printf("A=%d, B=%d\n", a, b); // but debugger shows the correct values in data window
// fflush(stdout);
return EXIT_SUCCESS; // error on this line
}
Added later: After some more debugging, I figured that even after the exit-error, if I do a "continue", then I am getting the lines on the console after the program terminates. So I added extra "fflush(stdout)" lines, and now I can see the outputs when they are being printed.
But how to fix the exit-error problem? Also, editing the file to add fflush to see debug outputs is a pain - is there a way to avoid this? Can somebody help me with this very basic problem, or point me to a place where the solution is given? Thanks in advance.
While logically a C program begins at int main() and ends when that function returns, environments (like Windows or Cygwin) frequently add pre- and post-code, for initializing / breaking down memory management, opening / closing standard streams, and other such bookkeeping. An executable compiled with Cygwin, after returning from int main(), switches to a cleanup function _cygwin_exit_return(), provided by the Cygwin runtime - for which you don't have sources, so your debugger complains.
As for getting the output immediately, you could use an unbuffered output stream.
Option one, use fprintf( stderr, ... ) (since stderr is by definition unbuffered). This, however, also affects the non-debugging behaviour of your program.
Option two:
int main()
{
// Using NDEBUG as also used by <assert.h>; feel free to use a different define
#ifndef NDEBUG
// For debugging, set stdout to unbuffered
setbuf( stdout, NULL );
#endif
....
Back when I was learning multithreading I was curious if threads were any faster than processes, and iirc I had to fflush even stderr/stdout on windows.
Memories aside, you can wrap those printf() in a function that calls fflush, or call setvbuf() to disable buffering.
About the exit: "no source available" only means that a part of your program lacks the info for debugging, so it's not a real error -- unless you build cygwin yourself, I guess the cygwin dll is stripped of debug symbols. Or maybe you want to debug cygwin's exit()?
EDIT: crap, concurrent answers :)
Hullo,
When one disasembly some win32 exe prog compiled by c compiler it
shows that some compilers links some 'hidden' routines in it -
i think even if c program is an empty one and has a 5 bytes or so.
I understand that such 5 bytes is enveloped in PE .exe format but
why to put some routines - it seem not necessary for me and even
somewhat annoys me. What is that? Can it be omitted? As i understand
c program (not speaking about c++ right now which i know has some
initial routines) should not need such complementary hidden functions..
Much tnx for answer, maybe even some extended info link, cause this
topic interests me much
//edit
ok here it is some disasembly Ive done way back then
(digital mars and old borland commandline (i have tested also)
both make much more code, (and Im specialli interested in bcc32)
but they do not include readable names/symbols in such dissassembly
so i will not post them here
thesse are somewhat readable - but i am not experienced in understending
what it is ;-)
https://dl.dropbox.com/u/42887985/prog_devcpp.htm
https://dl.dropbox.com/u/42887985/prog_lcc.htm
https://dl.dropbox.com/u/42887985/prog_mingw.htm
https://dl.dropbox.com/u/42887985/prog_pelles.htm
some explanatory comments whats that heere?
(I am afraid maybe there is some c++ sh*t here, I am
interested in pure c addons not c++ though,
but too tired now to assure that it was compiled in c
mode, extension of compiled empty-main prog was c
so I was thinking it will be output in c not c++)
tnx for longer explanations what it is
Since your win32 exe file is a dynamically linked object file, it will contain the necessary data needed by the dynamic linker to do its job, such as names of libraries to link to, and symbols that need resolving.
Even a program with an empty main() will link with the c-runtime and kernel32.dll libraries (and probably others? - a while since I last did Win32 dev).
You should also be aware that main() is only the entry point of your program - quite a bit has already gone on before this point such as retrieving and tokening the command-line, setting up the locale, creating stderr, stdin, and stdout and setting up the other mechanism required by the c-runtime library such a at_exit(). Similarly, when your main() returns, the runtime does some clean-up - and at the very least needs to call the kernel to tell it that you're done.
As to whether it's necessary? Yes, unless you fancy writing your own program prologue and epilogue each time. There are probably are ways of writing minimal, statically linked applications if you're sufficiently masochistic.
As for storage overhead, why are you getting so worked up? It's not enough to worry about.
There are several initialization functions that load whenever you run a program on Windows. These functions, among other things, call the main() function that you write - which is why you need either a main() or WinMain() function for your program to run. I'm not aware of other included functions though. Do you have some disassembly to show?
You don't have much detail to go on but I think most of what you're seeing is probably the routines of the specific C runtime library that your compiler works with.
For instance there will be code enabling it to run from the entry point 'main' which portable executable format understands to call the main(char ** args) that you wrote in your C program.