RIZZI@USC-ISIB.ARPA (01/31/86)
I am porting a UNIX application written in C to VAX/VMS. Aside from file name translation, the biggest problem I have is in dealing with code that blithely dereferences NULL pointers, expecting a zero or null string. My understanding is that UNIX allows this, however VMS insists on an access violation which is disastrous. Not only does much of the application code ignore NULL pointers, but the VAX/VMS C runtime library does as well!! printf() and strcpy() among others are easily convinced to crash and burn. I have been able to catch the SIGBUS signal, using both signal() and sigvec() (VMS-specific), but have not been able to ignore it or return from my handler without a stack trace and program exit. I suspect that some mucking about with the sigcontext structure that arrives with a sigvec()-style signal might produce better results, but I am reluctant to attempt this. Is there someway available to recover from or ignore the SIGBUS signal or am I fated to pore thousands of lines of code in search of potential NULL pointer dereferences?? Thanks, Bill ARPA: RIZZI@ISIB UUCP: cca!ima!ism780b!billr -------
info-vax@ucbvax.UUCP (02/03/86)
You are not alone..... The Pr1ime C compiler is in danger of the same thing due to the difference between a"NULL" and the defined NULL. In most of the C world NULL is some concept con- cerning "0"... this is not the real case. What we want for "NULL" is really a C cast called "(char *) 0" which really means a pointer valuse to 0. I have already been trapped by a lot of custom code whre "NULL" has been defined as everyting from "0" to "(long *) 0". I suggest you check out hoe NULL has been defined on your machine and hoe it is expected to be by the code you are porting. the everloving C language cast is USEFUL!! ...iamanint = (int) iamapointer....
roger@LL-VLSI (Roger Hale) (02/03/86)
In reply to mb2c!eed092!root (epsilon!root?)'s article <8602030356.AA03669@epsilon.UUCP> of Sun, 2 Feb 86 22:56:37 est: > You are not alone..... The Pr1me C compiler is in danger > of the same thing due to the difference between a"NULL" and the > defined NULL. In most of the C world NULL is some concept con- > cerning "0"... this is not the real case. What we want for "NULL" > is really a C cast called "(char *) 0" which really means a pointer > value to 0. I have already been trapped by a lot of custom code > whre "NULL" has been defined as everything from "0" to "(long *) 0". > > I suggest you check out how NULL has been defined on your > machine and how it is expected to be by the code you are porting. > the everloving C language cast is USEFUL!! > ...iamanint = (int) iamapointer.... This is a topic that keeps coming up in info-c (AKA net.lang.c) at least once a year, and epsilon!root(?)'s position here is somewhat off the mark. There are two parts to this problem, epsilon!root's problem of getting NULL to become your current type of null pointer when you want one, and the problem in the subject line of not checking that a pointer is null before following it. If I may try to present The consensus answer to the first: #define NULL 0 IS CORRECT, and NULL should always be assigned, cast, or compared to the desired pointer type at its point of use (I think that covers reasonable uses). That is, type *typep = NULL; /* initializing */ typep = NULL; /* assigning */ if (typep == NULL) /* comparing */ error("oops!"); if ((typep = (type *)calloc(1, sizeof(type))) == NULL) /* again */ error("oops!"); func( (type *)NULL ); /* cast *all* NULL arguments! (as long as you can't declare their types) */ In particular an uncast NULL argument might as well be 0, since (type1 *)0 may look entirely different from both (type2 *)0 and from 0 itself! NULL being 0 is needed for portability (1) to such machines as the Pr1me, Livermore S-1, or (dare one think it?) Lisp Machine where pointers may have their types built in, and (2) to compilers that (reasonably?) don't recognize `(char *)0' as "the constant 0". As for the original problem, of porting a program that follows null pointers and starts dumping core or worse, I suppose you have two choices: (1) beat up on your source to fix it or (2) beat up on the sources yourself. It all depends who you're getting it from. Or maybe (3) punt. Yours, Roger Hale <roger@ll-sst.arpa>
info-vax@ucbvax.UUCP (02/06/86)
In article <8602030356.AA03669@epsilon.UUCP> you write: > > > > You are not alone..... The Pr1ime C compiler is in danger > of the same thing due to the difference between a"NULL" and the > defined NULL. In most of the C world NULL is some concept con- > cerning "0"... this is not the real case. What we want for "NULL" > is really a C cast called "(char *) 0" which really means a pointer > valuse to 0. Wrong. Look at the current draft standard on C. This subject has been discussed at great length before and the correct answer is that NULL is equal to a constant value of zero. Steve Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl +1 408 746 6970