robert@triton.jpl.nasa.gov (Robert Angelino) (06/07/91)
I have this code that keeps going out to lunch. Any suggestions
are welcome.
#ifdef vms
char cur_time[26];
const char *ptr = (cur_time + 7);
int status = 0,
i = 0;
$DESCRIPTOR(cur_time_desc,cur_time);
#endif
/* Extract the year from the time */
#ifdef vms
if(((status = LIB$DATE_TIME(&cur_time_desc)) &1) != 1)
return((jtm*)0);
cur_time[11] = '\0';
#ifdef DEBUG
printf("ptr = %s\n",ptr);
#endif
date->tm_year = atoi(ptr);
#endif
It CRASHES at the "atoi" call.
This is the output I get from the run:
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000014,
PC=0000D8D9, PSL=03C00000
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
JTMSYSTEM jtm_system 2577 00000085 0000D8D9
TC_TASK tcr_sprintf 2375 00000028 0000AE00
TC_TASK write_rec 2476 0000014D 0000B059
ADCC update_adcc_data_table 1829 0000002F 0000754B
USER_I user_interface_ml 4891 00000363 0000C403
SPA_TCLKUTC main 2642 000002A9 0000718D
These are the logicals I'm using as the libraries:
"LNK$LIBRARY" = "SYS$LIBRARY:VAXCCURSE"
"LNK$LIBRARY_1" = "SYS$LIBRARY:VAXCRTL"
I've tried the following and it still crashes:
char *ptr = (char*) 0;
.
.
.
cur_time[11] = '\0';
ptr = cur_time + 7;
date->tm_year = atoi((const char*) ptr);
--
- ------ - Robert Angelino
| | | ---- \ | | ms T-1704L
| | | | \ | | | 4800 Oak Grove Drive
| | | | -- | | | Pasadena, CA 91109
---| | | | \__/ | |___ robert@triton.jpl.nasa.gov
\____|et |_|ropulsion |_____\aboratory (818) 354-9574rankin@eql7.caltech.edu (Pat Rankin) (06/08/91)
In article <6246@mahendo.Jpl.Nasa.Gov>, robert@triton.jpl.nasa.gov (Robert Angelino) writes... > I have this code that keeps going out to lunch. Any suggestions > are welcome. Why all the VMS-specific date/time manipulation? time(), mktime() and asctime() work fine. If you can't use mktime() for some reason, then SYS$NUMTIM() will fill in an array of date/time fields. > date->tm_year = atoi(ptr); > It CRASHES at the "atoi" call. > %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000014, 'date' is almost certainly a NULL pointer. Perhaps it's time to learn how to use the debugger? Pat Rankin, rankin@eql.caltech.edu
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/11/91)
In article <6246@mahendo.Jpl.Nasa.Gov>, robert@triton.jpl.nasa.gov (Robert Angelino) writes: > I have this code that keeps going out to lunch. [...code which doesn't mention `date' anywhere...] > date->tm_year = atoi(ptr); > It CRASHES at the "atoi" call. I think it far likelier that the atoi call works perfectly well and the assignment fails, probably because date is a null pointer. > This is the output I get from the run: > %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000014, PC=0000D8D9, PSL=03C00000 > %TRACE-F-TRACEBACK, symbolic stack dump follows [...] This makes it even more likely. The virtual address given is 0x14, which is precisely what you'd see for the tm_year member of a null pointer to struct tm. (The tm_year is the 6th int in the structure on most machines, and on a VAX that normally translates into an offset of 0x14 from the beginning of the structure.) > I've tried the following and it still crashes: > cur_time[11] = '\0'; > ptr = cur_time + 7; > date->tm_year = atoi((const char*) ptr); I imagine date is still a null pointer; if so, diddling with atoi won't do squat. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu