> It compiles without error, but if i run it from the console it will > generate a segmentation fault error.
Once I add
#include <assert.h>
it compiles and runs without error for me (tested under Cygwin, Ubuntu,
and Solaris).
assert() is defined as a macro. My best guess is that you have a
function or other symbol with the same name defined somewhere in your
library, and your compiler is permitting the implicit declaration and
calling that function, which is incompatible with the assert() macro.
Try adding "#include <assert.h>" and see if that fixes it.
Incidentally, what is the purpose of
#define NIL (0)
? Why not just use the predefined NULL macro? And in any case, the
parentheses in the definition are unnecessary (but harmless).
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
>> It compiles without error, but if i run it from the console it will
>> generate a segmentation fault error.
> Once I add
> #include<assert.h>
> it compiles and runs without error for me (tested under Cygwin, Ubuntu,
> and Solaris).
> assert() is defined as a macro. My best guess is that you have a
> function or other symbol with the same name defined somewhere in your
> library, and your compiler is permitting the implicit declaration and
> calling that function, which is incompatible with the assert() macro.
> Try adding "#include<assert.h>" and see if that fixes it.
> Incidentally, what is the purpose of
> #define NIL (0)
> ? Why not just use the predefined NULL macro? And in any case, the
> parentheses in the definition are unnecessary (but harmless).
Hi Keith,
I got it to run under debian but i am having problems getting it to work on the console / terminal in freebsd. I have been trying to find out if a window manager is necessary to run this but am not able to find clear documentation on this point. I am trying to get this to work on a system that does have x windows configured - but I am not invoking it from within x windows.
Regards
>>> It compiles without error, but if i run it from the console it will
>>> generate a segmentation fault error.
>> Once I add
>> #include<assert.h>
>> it compiles and runs without error for me (tested under Cygwin, Ubuntu,
>> and Solaris).
>> assert() is defined as a macro. My best guess is that you have a
>> function or other symbol with the same name defined somewhere in your
>> library, and your compiler is permitting the implicit declaration and
>> calling that function, which is incompatible with the assert() macro.
>> Try adding "#include<assert.h>" and see if that fixes it.
>> Incidentally, what is the purpose of
>> #define NIL (0)
>> ? Why not just use the predefined NULL macro? And in any case, the
>> parentheses in the definition are unnecessary (but harmless).
Hmm, that's odd. I definitely wrote "#include <assert.h>" both times,
with a space between "#include" and "<", but the quoted material in your
followup shows it as "#include<assert.h>" without the space. Did your
newsreader do that?
Anyway ...
> I got it to run under debian but i am having problems getting it to
> work on the console / terminal in freebsd. I have been trying to find
> out if a window manager is necessary to run this but am not able to
> find clear documentation on this point. I am trying to get this to
> work on a system that does have x windows configured - but I am not
> invoking it from within x windows.
Did you try adding the "#include <assert.h>" as I suggested? Did it
make a difference?
A window manager shouldn't be necessary, as long as you have a usable X
server running. But it would be quite unusual to be running an X server
with no window manager.
And if you don't, the assert() should fail unless you've defined NDEBUG.
But really, assert() should be used to catch programming errors, not
run-time errors. It's a way of saying "This should never happen, but if
it does, tell me about it and give up on doing anything else."
For XOpenDisplay(NULL) to work, you need to have the environment
variable $DISPLAY set to something valid, such as ":0.0". This *should*
be set for you automatically. Try running a simple known-to-work X11
program such as xlogo; this will tell you whether it's a problem with
the X server or a problem in your program.
First see if you can get the assert() to work without causing a
segmentation fault. Then I suggest replacing the assert() with
something like:
if (dpy == NULL) {
fprintf(stderr, "XOpenDisplay failed\n");
exit(EXIT_FAILURE);
}
And what *exactly* does "problems getting it to work" mean? Is this
still the segmentation fault problem?
If your problem is with X11, you might try posting in one of the
comp.windows.x newsgroups (assuming they're still active, I haven't
visited lately).
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ike Naar <i...@faeroes.freeshell.org> writes:
> On 2012-08-08, nvangogh <nvang...@invalid.net> wrote:
>> I am trying to get this to work on a system >> that does have x windows configured - but I am not invoking it from >> within x windows.
> If the DISPLAY environment variable is not pointing to a
> working X display,
> Display *dpy = XOpenDisplay(NULL);
> will not succeed, and dpy will be set to NULL.
Which he checks for, but I suspect the check isn't being done correctly.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Christian Freund" <fre...@wrz.de> writes:
> "Keith Thompson" schrieb im Newsbeitrag > news:lnvcgtui75.fsf@nuthaus.mib.org...
>> Display *dpy = XOpenDisplay(NULL);
>> will not succeed, and dpy will be set to NULL.
> Which he checks for, but I suspect the check isn't being done correctly.
> __
> Please "nvangogh" instead of that assert() try out something like:
> "if(!dpy) return 0xffff;"
> Or finally use a debugger, or print out the return-codes of everything on > stderr.
Christian, quoted text should be marked by prepending "> " to each line.
Your newsreader *should* do this for you.
Returning 0xffff from main() is not a good idea. If you want to do that
kind of error check, you can do `return EXIT_FAILURE;` or
`exit(EXIT_FAILURE);`, both of which require `#include <stdlib.h>`.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Francis Glassborow <francis.glassbo...@btinternet.com> writes:
> On 28/08/2012 09:51, Keith Thompson wrote:
>> "Christian Freund" <fre...@wrz.de> writes:
>>> "Keith Thompson" schrieb im Newsbeitrag
>>> news:lnvcgtui75.fsf@nuthaus.mib.org...
>>>> Display *dpy = XOpenDisplay(NULL);
>>>> will not succeed, and dpy will be set to NULL.
>>> Which he checks for, but I suspect the check isn't being done correctly.
>>> __
>>> Please "nvangogh" instead of that assert() try out something like:
>>> "if(!dpy) return 0xffff;"
>>> Or finally use a debugger, or print out the return-codes of everything on
>>> stderr.
>> Christian, quoted text should be marked by prepending "> " to each line.
>> Your newsreader *should* do this for you.
> I am sure it would if he had not replied below the '__' signature separator.
"__" isn't a signature separator; "-- " is (the trailing space is part
of it).
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
