bug-libmatheval
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-libmatheval] Re: crash in libmatheval, on 64 bit arch's (AMD64)


From: Aleksandar B. Samardzic
Subject: [Bug-libmatheval] Re: crash in libmatheval, on 64 bit arch's (AMD64)
Date: Sat, 13 Aug 2005 10:16:40 +0200
User-agent: Mutt/1.4.2.1i

> Date: Thu, 11 Aug 2005 16:58:58 -0700 (PDT)
> From: Dave Andruczyk <address@hidden>
> Subject: crash in libmatheval, on 64 bit arch's (AMD64)
> To: address@hidden
> 
> I had a user of my software report a segfault regarding
> libmatheval. (I used a version of it and integrated it into my
> program, with no modificatiosn to it's routines)
> 
> Here's the GDB info:
> 
>  Program received signal SIGSEGV, Segmentation fault. 
>  [Switching to Thread 46912564793952 (LWP 1465)] 
>  hash (s=0x0, n=211) at symbol_table.c:258 
>  258             for (p = s; *p; p++) { 
>  (gdb) 

Dave,

What is the expression evaluated and for which variable values?  Just
tried libmatheval 1.1.1 (btw, you may wish to upgrade to 1.1.2) on an
AMD 64 machine and all tests from libmatheval test suite passed...


> I looked into that function (libmatheval 1.1.1) and there isn't
> anything there that checks the size of the pointers. (I believe
> pointers on 64 bit arch's are 64 bits wide, not 32 bit,)

Indeed, but I see no issue with this here.


> The other inconsistency is that "h" ad "g" are not defined to be an
> explicit type. (they are just declared as "unsigned" not unsigned
> {char, int, float, long, long long, etc}..)

The type "unsigned" is same as "unsigned int" according to the standard
(K&R book is full of examples using "unsigned" only, one of these is
actually hash function too), so I don't believe this has to do with this
crash either.  But let me know about offending expression and I'll
double check.

Regards,
Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]