Re: how serious are these compiler warnings?

[Rick Jones <rick jones2 hp com>]

Michael L Torrie wrote:
> On Wed, 2006-04-05 at 15:30 -0700, Rick Jones wrote:
>
> > which seems to be an issue with the callback function field of the 
> > GOptionEntry.  Do folks think it is something really worth worrying 
> > about or should I just blythly ignore it and move-on?
>
>
> While it appears that this is harmless, I'd recommend that you
> explicitly cast your functions to (void*).  You'd actually have to do
> this with pointers to integers as well.
>
> The reason this is required is that GOptionEntry only wants (void *)
> which it casts to either to the type you specified, whether it be an
> integer or a function.  So it is up to you to explicitly cast, or let
> the compiler do it for you.  Explicit casting is safer (prevents
> mistakes).

OK, I'll do that.... time passes...

yep, the compiler (invoked as xlc_r now since this is threaded) has 
stopped complaining.  Alas, I still segfault at the end of my test.  It 
looks like my g_module_open()ed library may be dying right at a call to 
a routine that is actually in the program itself.  Having just learned 
that doing that is not possible in a DLL under Windows I'm left 
wondering if there are issues with that under AIX

rick jones

# ./netperf
Segmentation fault(coredump)
# dbx ./netperf core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...

Segmentation fault in glink.fflush at 0xd1fda988 ($t1)
0xd1fda988 (fflush+0x30) 800c0000        lwz   r0,0x0(r12)
(dbx) dump
glink.fflush() at 0xd1fda988
(dbx) registers
  $r0:0xd1fd31dc  $stkp:0x2ff22990   $toc:0xf0cf5350    $r3:0x2008b488
  $r4:0x2001adbc    $r5:0x2008b3e8    $r6:0x2ff229e0    $r7:0x00000000
  $r8:0x100b1091    $r9:0x100b1091   $r10:0x2002e1d8   $r11:0x00000000
 $r12:0x0147e600   $r13:0xdeadbeef   $r14:0x00000001   $r15:0x2ff22c8c
 $r16:0x2ff22c94   $r17:0x00000000   $r18:0xdeadbeef   $r19:0xdeadbeef
 $r20:0xdeadbeef   $r21:0xdeadbeef   $r22:0xdeadbeef   $r23:0xdeadbeef
 $r24:0xdeadbeef   $r25:0xdeadbeef   $r26:0xdeadbeef   $r27:0xdeadbeef
 $r28:0xdeadbeef   $r29:0xdeadbeef   $r30:0x20004b38   $r31:0xd1fdb360
 $iar:0xd1fda988   $msr:0x0000d0b2    $cr:0x22282388  $link:0xd1fd40f4
 $ctr:0xd0132a80   $xer:0x20000008    $mq:0xdeadbeef
          Condition status = 0:e 1:e 2:e 3:l 4:e 5:eo 6:l 7:l
        [unset $noflregs to view floating point registers]
        [unset $novregs to view vector registers]
in glink.fflush at 0xd1fda988 ($t1)
0xd1fda988 (fflush+0x30) 800c0000        lwz   r0,0x0(r12)

not knowing anything about Power assembly, but guessing, is that a wide 
load into r0 of something zero bytes from the address in r12?

(dbx) up
update_results_and_confidence(test_set = 0x2001ad98), line 2828 in 
"nettest_bsd.c"
(dbx) list
 2828     confidence                    = get_confidence(rd->run_time,
 2829                                         &(test_set->confidence),
 2830                                         &(rd->ave_time),
 2831                                         &(temp));
 2832     rd->result_confidence         = get_confidence(rd->results,
 2833                                         &(test_set->confidence),
 2834                                         &(rd->result_measured_mean),
 2835                                         &(rd->result_interval));
 2836     if (test_set->debug) {
 2837       fprintf(test_set->where,
(dbx) dump
update_results_and_confidence(test_set = 0x2001ad98), line 2828 in 
"nettest_bsd.c"
rd = 0x2008b3b8
temp = 4.1126813125747635e-314
__func__ = "update_results_and_confidence"
confidence = 1.0

what is particularly perplexing is that while there is a fflush() call 
above line 2828, it is inside an if{} that I know is not being executed, 
which means that fflush was not executed so I'm rather confused about 
dbx showing fflush at the end of the call chain.