Hi Lewis,
I think the root problem is that %d (and other conversion types) expect
a
pointer to an int, not a long. Initializing the l and ul variables
just gives you
consistency, not correct behavior. Also, if you want to use "%ld" to
allow
for values over 32 bits, you'd need to extend the code to check for the
'l'
modifier, similar to what it's doing for the 'h' modifier.
case 'd': case 'i':
if (s[-1] == 'h') {
sscanf(ps->s, ps1->s, &h);
ps->d = (double)h;
} else if (s[-1] == 'l') {
sscanf(ps->s, ps1->s, &l);
ps->d = (double)l;
} else {
sscanf(ps->s, ps1->s, &i);
ps->d = (double)i;
}
There are other type modifiers besides 'h' and 'l', but the code isn't
checking
for them so use of type modifiers such as "ll", "L", "hh", etc will
also cause
problems.
Regards,
- Bruce
On 08/18/2011 02:41 PM, J. Lewis Muir wrote:
On 8/18/11 3:26 PM, Tim Mooney wrote:
Awesome! I haven't reproduced the symptom on my x86_64 system, but
anyway it's clear that the code needs this fix. I'll look for other
similar problems.
Thanks to you both.
Tim
Hi, Tim.
I think I've found another problem: using SSCANF to parse '-1'
with a '%d' format does not result in a value of -1. Attached
is scalcout-corrupt2.db which demonstrates this. After loading
it into an IOC, I did the following from a Bash shell:
$ caget ioc23:Temperature.{VAL,SVAL}
ioc23:Temperature.VAL 4.29497e+09
ioc23:Temperature.SVAL 4294967295.000
The value should be -1.
Like the previous problem, it works fine with the i386
architecture class.
And if I change the '%d' to '%ld', it works fine for the x86_64
architecture class.
Thanks,
Lewis
--
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA 94025
|