passing a structure and casting it void -- help please

[Mike]

I am trying to call a function that is defined as .. function x (char
*item , void *key)

I have a struct :

struct guide_options {
mvp_widget_t *mywidget;
char *myitem;
};

main () {

struct guide_options guideptr;

// then fill the struct
guideptr.mywidget = widget2;
guideptr.myitem = buf;

x ( (char*)i , (void*)&guideptr);

But it seg faults. Can someone point me in a direction.

Thank you, Mike

[Ian Collins]

Mike wrote:

I am trying to call a function that is defined as .. function x (char
*item , void *key)

I have a struct :

struct guide_options {
mvp_widget_t *mywidget;
char *myitem;
};

main () {

struct guide_options guideptr;

// then fill the struct
guideptr.mywidget = widget2;
guideptr.myitem = buf;

x ( (char*)i , (void*)&guideptr);

What is i and why are you casting it? Why cast &guideptr?

But it seg faults. Can someone point me in a direction.

Not without the guts of x().

--
Ian Collins.

[akina]

>

But it seg faults. Can someone point me in a direction.

The best way to debug this issue would be to use a debugging tool (GDB)
to analyse your code with the core dump. This should tell you the line
where the fault is and will make it easier to nail down the exact
issue.
Make sure you compile your program with the -g option before running
the binary.

/A

[jmcgill]

Mike wrote:

But it seg faults. Can someone point me in a direction.

You might find the error very quickly by running your program under
strace or truss.

Plenty of times, segv errors suppress the output or can mislead you in
other ways, and I often find truss shows me more.

At the source level, you might use a static checking utility like lint,
and some of us in the 21st century are using splint (www.splint.org).

If you are trying to debug a problem involving your use of malloc/free,
on a unix-ish environment, you might find electric fence useful. You
link to it, and it basically overrides malloc() and free() and lets you
watch your program die by its own hand in the debugger.

It's not always obvious where a segfault is really happening. You may
think you know where the problem is, and beat your head flat trying to
fix it, when the real bug is somewhere else entirely.

[Herbert Rosenau]

On Wed, 9 Aug 2006 01:02:45 UTC, "Mike" <md****@yahoo.comwrote:

I am trying to call a function that is defined as .. function x (char
*item , void *key)

I have a struct :

struct guide_options {
mvp_widget_t *mywidget;
char *myitem;
};

main () {

struct guide_options guideptr;

// then fill the struct
guideptr.mywidget = widget2;
guideptr.myitem = buf;

x ( (char*)i , (void*)&guideptr);

But it seg faults. Can someone point me in a direction.

You are lying to the compiler and the compiler gets its revange.

Never ever use a cast when you are not exactly knows what you are
doing. And you shows that you are not about ab knows what you are
doing.

Learn the differencer between pointer and pointer to pointer.

Set your compiler options to the hardes possible warning level and try
to run your program only if the compier will not output a single error
or wearning.

And again: do not cast until you understunds what you are doing.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Default User]

akina wrote:

But it seg faults. Can someone point me in a direction.

The best way to debug this issue would be to use a debugging tool
(GDB) to analyse your code with the core dump. This should tell you
the line where the fault is and will make it easier to nail down the
exact issue.
Make sure you compile your program with the -g option before running
the binary.

What did the OP say that made you assume he was using gcc?


Brian

[Harald van Dijk]

Default User wrote:

akina wrote:

>
But it seg faults. Can someone point me in a direction.

The best way to debug this issue would be to use a debugging tool
(GDB) to analyse your code with the core dump. This should tell you
the line where the fault is and will make it easier to nail down the
exact issue.
Make sure you compile your program with the -g option before running
the binary.

What did the OP say that made you assume he was using gcc?

What did akina say that made you assume he assumed the OP was using gcc?
(It's possible that gcc was indeed assumed, but I only see an assumption of
a Unix-like system, which is a fairly reasonable one, considering the "seg
faults".)

[Default User]

Harald van Dijk wrote:

Default User wrote:

What did the OP say that made you assume he was using gcc?

What did akina say that made you assume he assumed the OP was using
gcc? (It's possible that gcc was indeed assumed, but I only see an
assumption of a Unix-like system, which is a fairly reasonable one,
considering the "seg faults".)

He mentioned gdb, with instructions on how build the executable to make
it compatible with that.


Brian

[Harald van Dijk]

Default User wrote:

Harald van Dijk wrote:

>Default User wrote:

What did the OP say that made you assume he was using gcc?

What did akina say that made you assume he assumed the OP was using
gcc? (It's possible that gcc was indeed assumed, but I only see an
assumption of a Unix-like system, which is a fairly reasonable one,
considering the "seg faults".)

He mentioned gdb, with instructions on how build the executable to make
it compatible with that.

-g is one of the few compiler options specified by POSIX and is implemented
by icc, tendra, tinycc, gcc, sun's compiler and more, gdb was only
mentioned as an example of a debugger, and gdb also works with code
generated by other compilers. (gcc's debugging formats are not unique to
gcc.)

[akina]

>
What did the OP say that made you assume he was using gcc?

Brian

"it seg faults" suggests that he is using a unix based system. And GCC
is a commonly used compiler in these systems. I guess there is no harm
in assuming this.
Probably I should have mentioned this in my post.

Anyways, it is "OP" who should say if my suggestion was useful or not.

[Default User]

Harald van Dijk wrote:

Default User wrote:

Harald van Dijk wrote:

Default User wrote:

What did the OP say that made you assume he was using gcc?

What did akina say that made you assume he assumed the OP was using
gcc? (It's possible that gcc was indeed assumed, but I only see an
assumption of a Unix-like system, which is a fairly reasonable one,
considering the "seg faults".)

He mentioned gdb, with instructions on how build the executable to
make it compatible with that.

-g is one of the few compiler options specified by POSIX and is
implemented by icc, tendra, tinycc, gcc, sun's compiler and more, gdb
was only mentioned as an example of a debugger, and gdb also works
with code generated by other compilers. (gcc's debugging formats are
not unique to gcc.)

Ok, granted. Let's amend to, "What did the OP say that made you assume
he was using UNIX?"


Brian