Pelles C forum
C language => Beginner questions => Topic started by: tpekar on March 08, 2013, 11:12:07 PM
-
I am having trouble getting the following program to run. I know I am doing something wrong but can't figure out what it is. It compiles and runs the qsort but crashes when it tries to do the bsearch. Can someone help? Thanks!
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char source[129]="";
char *dta[5]={"muid","epicsid","ssn","inst","chkdat"};
char *rec[200];
char input[256];
char key[10];
char *ans;
int i,e;
int main(int argc, char *argv[]) {
int strcmp();
int compare(const void *arg1, const void *arg2);
for (i=0;i<5;i++) {
strcpy(input,dta[i]);
rec[i]=malloc(strlen(input)+1);
strcpy(rec[i],input);
}
qsort((void *)rec,(size_t)i,sizeof(char *),compare);
e=i;
for (i=0;i<e;i++) printf("%s\n",rec[i]);
strcpy(key,"inst");
ans=bsearch(key,(void *)rec,(size_t)e,sizeof(char *),compare);
if (ans!=NULL) printf("\nfound inst");
strcpy(key,"inst1");
ans=bsearch(key,(void *)rec,(size_t)e,sizeof(char *),compare);
if (ans==NULL) printf("\ndid not find inst1");
}
int compare(const void *arg1, const void *arg2) {
return strcmp(* (char**) arg1, * (char**) arg2);
}
-
You can read the error messages emitted by the compiler.
-
I am having trouble getting the following program to run. I know I am doing something wrong but can't figure out what it is. It compiles and runs the qsort but crashes when it tries to do the bsearch. Can someone help? Thanks!
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char source[129]="";
char *dta[5]={"muid","epicsid","ssn","inst","chkdat"};
char *rec[200];
char input[256];
char key[10];
char *ans;
int i,e;
int main(int argc, char *argv[]) {
int strcmp();
int compare(const void *arg1, const void *arg2);
for (i=0;i<5;i++) {
strcpy(input,dta);
rec=malloc(strlen(input)+1);
strcpy(rec,input);
}
qsort((void *)rec,(size_t)i,sizeof(char *),compare);
e=i;
for (i=0;i<e;i++) printf("%s\n",rec);
strcpy(key,"inst");
ans=bsearch(key,(void *)rec,(size_t)e,sizeof(char *),compare);
if (ans!=NULL) printf("\nfound inst");
strcpy(key,"inst1");
ans=bsearch(key,(void *)rec,(size_t)e,sizeof(char *),compare);
if (ans==NULL) printf("\ndid not find inst1");
}
int compare(const void *arg1, const void *arg2) {
return strcmp(* (char**) arg1, * (char**) arg2);
}
You mean other than mismatched brackets, typecasting for no reason at all and code that's so poorly formatted as to be almost impossible to follow?
-
For anyone who doesn't know Pelle provides a C formatting feature.
Highlight the section of code that needs formatting, then from the menu - Source/Convert to/Formatted C code
John
-
It compiles and runs the qsort but crashes when it tries to do the bsearch.
Hi tpekar,
Which options did you use? I get some compile errors, see below.
Your wording suggests that you can compile the code, but the executable crashes. Does it throw an exception? The easiest way to test why would be to launch a debugger (e.g. Olly (http://www.ollydbg.de/version2.html)) and see where it chokes.
Building qSortCrash.obj.
qSortCrash.c(15): error #2140: Type error in argument 2 to 'strcpy'; expected 'const char * restrict' but found 'char * *'.
qSortCrash.c(16): error #2168: Operands of '=' have incompatible types 'char * [200]' and 'void *'.
qSortCrash.c(16): error #2088: Lvalue required.
qSortCrash.c(17): error #2140: Type error in argument 1 to 'strcpy'; expected 'char * restrict' but found 'char * *'.
qSortCrash.c(21): warning #2234: Argument 2 to 'printf' does not match the format string; expected 'char *' but found 'char * *'.
-
Your wording suggests that you can compile the code, but the executable crashes. Does it throw an exception? The easiest way to test why would be to launch a debugger (e.g. Olly (http://www.ollydbg.de/version2.html)) and see where it chokes.
Pelles C has a built in source level debugger... no need for external tools.
-
It compiles and runs the qsort but crashes when it tries to do the bsearch. Can someone help?
...
char *pkey = key;
ans = bsearch(&pkey, (void *)rec, (size_t)e, sizeof(char *), compare);
...
-
Pelles C has a built in source level debugger... no need for external tools.
You mean the one that shows the flags as 00000AC3? Hmmmm...
-
Pelles C has a built in source level debugger... no need for external tools.
You mean the one that shows the flags as 00000AC3? Hmmmm...
No... I mean the one that if used correctly can take you right to the line of source code that's causing your problems.
-
No... I mean the one that if used correctly can take you right to the line of source code that's causing your problems.
That one is called Olly, and among many other features displays the flags in a useful format (CZS etc, red if set, black if clear) and in a readable font.
-
No... I mean the one that if used correctly can take you right to the line of source code that's causing your problems.
That one is called Olly, and among many other features displays the flags in a useful format (CZS etc, red if set, black if clear) and in a readable font.
I have OllyDebug here... it's mostly useless in C projects.
Seriously... We need to correlate problems to lines of source code, not some silly dissassembly listing. Since we don't have direct access to the flags register in C --and don't need it-- there's no reason to care about how it's displayed.
Do you know how to use the internal debugger?
- Take any working project you have
- Load it into the IDE...
- Right click on the project name in the tree and select "Project Options".
- On the compiler tab select Debug Information = Full.
- On the linker tab... for 32 bit projects select Debug Information = CodeView & Coff... for 64 bit projects select Debug Information = Codeview.
- Click OK to save the settings.
Now, on the main toolbar click the "Go Debug" button....
If you can't see how that is more useful to a C programmer, you're a complete idiot.
-
If you can't see how that is more useful to a C programmer, you're a complete idiot.
Lovely ;D
-
Most of the times PellesC Debugger is more than enough
for the task.
G.
-
Most of the times PellesC Debugger is more than enough
for the task.
Hi Giovan...
You need to take into account where this is coming from...
Our friend JJ has it in his head that he's out to vanquish me for some wholly imagined slight on a different forum and thinks (wrongly) that he can come over here and show everyone how smart he is by going after me. In the end all he's doing is giving the people here some really BAD advice that I (and others) then have to try and fix.
Indeed Pelle's debugger is perfectly adequate for almost all C programming tasks.
It is afterall designed for exactly that purpose.
-
Most of the times PellesC Debugger is more than enough for the task.
It's not bad, actually. Probably just a question of habit, although I'd be grateful to know how the font could be changed in the register window, it's just unreadable.
Re Tater: He is just a bit upset (http://masm32.com/board/index.php?topic=1617.msg16517#msg16517) that his UTF-8 library works with English text only ;)
-
PLEASE guys, keep it down a bit, this is not the place for any personal rants/attacks...
As for the issue at hand, debugging C programs with a CPU level debugger for a case like this is IMHO as well nonsense. And the build-in debugger will work just fine for the task to track down the issue of the OP.
And for me personal, I don't see anything wrong with the font in the register window/tab of the debugger, though possibly using different colors for register name and their values might be a possible improvement.
Showing the CPU flags for plain C programs/libraries is pretty much useless, only when directly working with assembler sources this could eventually be an advantage...
Ralf
-
Ralf,
Even with my glasses I can't read that tiny font, so it is an issue.
In another thread on GetOpenFileName there is something going wrong deep inside the API - no problem for Olly but I doubt it would be easy with the in-built debugger. I'd be curious to test it (after all, how often can you find a real Windows bug?), but the GetOpenFileName misbehaviour seems almost impossible to reproduce...
-
Ralf,
Even with my glasses I can't read that tiny font, so it is an issue.
I am running all my screens at 1280x1024 or higher, with standard Windows font sizes everywhere and I don't have a problem at all. No glasses for me...
And beside that, as mentioned, when debugging C programs (or pretty much any high level language, Pascal, Fortran, C++, C#, just as examples) it is very rare that you need to go down to the CPU level at all. I am certain that 99.999% of all issues are in fact on the level of that high-level language...
In another thread on GetOpenFileName there is something going wrong deep inside the API - no problem for Olly but I doubt it would be easy with the in-built debugger. I'd be curious to test it (after all, how often can you find a real Windows bug?), but the GetOpenFileName misbehaviour seems almost impossible to reproduce...
Weird issue indeed and that this problem is reproducible with some standard Windows programs (like Notepad) seems to indicate that this is in fact a problem within the Windows API, not likely an issue with any program that is using it. And to track down, it would require debugging the code of the Windows API, at the level of the language it is written in (and I doubt that this is assembler in this case). That leaves pretty much the ball in Microsoft's court, if they would even remotely be interested to tracking this down...
Ralf
-
The text is not displayed correctly because you are asking the WINDOWS CONSOLE to display multiple languages (i.e. codepages) simultaneously and it can't do that. If you actually knew anything about Windows Unicode, you would know that.
Look at the source code... see the two calls MultiByteToWideChar() (http://msdn.microsoft.com/en-ca/library/windows/desktop/dd319072(v=vs.85).aspx) and WideCharToMultiByte() (http://msdn.microsoft.com/en-ca/library/windows/desktop/dd374130(v=vs.85).aspx) ?
Those are windows API calls
Tater, you are confused. The windows console has no problems displaying multiple languages - this is copied directly from the console:
UTF-8 text file created, now reading & printing
Введите текст здесь
Нажмите на эту кнопку
Добро пожаловать
أدخل النص هنا
دفع هذا الزر
مرحبا بكم
在這裡輸入文字
按一下這個按鈕
歡迎
And it has nothing to do with "multiple codepages", it's just one codepage, UTF-8.
Demo attached (Asiatic fonts need to be installed, and user must set Lucida Console, as usual). In case you know how to use a CPU level debugger, you may find references to MultiByteToWideChar() and WideCharToMultiByte, too.
Take care,
jj
P.S.: Apologies that the source is Assembler, not C. Open the *.asc file in WordPad. I hope it's self-explanatory. These are the lines that open the file, read the strings and display them in the console:
Recall "Utf8.txt", L$()
SetCpUtf8
For_ ebx=0 To eax-1
Print L$(ebx), CrLf$
Next
-
Tater, you are confused.
Not any more...
Because of you the price of generosity has become too high.
-
timovl,
Thanks for the fix. It worked. Apparently bsearch is looking for the address of a pointer. Is that like a pointer to a pointer?
-
Apparently bsearch is looking for the address of a pointer. Is that like a pointer to a pointer?
No, it is just the memory address where the value of the pointer is saved.
It is not the value of the pointer.
Think of it as the difference of by value and by reference.
If you have a variable pointer with the value 1234 located at address 6789 the following will apply for the argument passed to a function:
1) pointer ... the value 1234 will be passed to the function
2) &pointer ... the address 6789 will be passed to the function