cechew@bruce.OZ (Earl Chew) (11/10/89)
From article <4463@ast.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum): > Does this one look better? I think I have the case of both bytes 0 Umm... well, everything except for: > #define _HIGH(__v) ( (__v >> 8) & 0377) Would be safer to protect __v in parentheses: #define _HIGH(__v) ( ((__v) >> 8) & 0377) > #define WIFSIGNALED(__s) (_HIGH(__s) == 0 && __s != 0) /* signaled */ You can get by without evaluating __s _twice_ (macros with side-effects and all that) (and again, you didn't protect (__s) != 0 in parentheses): #define WIFSIGNALED(__s) ((unsigned int) ((__s) - 1 & 0xffff) < 0xff) __s is evaluated only once. I don't know if Posix allows these macros to be `unsafe' (ie evaluate arguments more than once). In any event, it's safer this way (probably more efficient also --- only one test required instead of two). Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 ARPA: cechew%bruce.cs.monash.oz.au@uunet.uu.net ACS : cechew@bruce.oz ----------------------------------------------------------------------
ast@cs.vu.nl (Andy Tanenbaum) (11/11/89)
In article <1684@bruce.OZ> cechew@bruce.OZ (Earl Chew) writes: >#define WIFSIGNALED(__s) ((unsigned int) ((__s) - 1 & 0xffff) < 0xff) You may be right, but I find mine an awful lot clearer: #define WIFSIGNALED(--s) (_HIGH(__s) == 0 && __s != 0) Does anyone know if mine is ok? Andy Tanenbaum (ast@cs.vu.nl)
cechew@bruce.OZ (Earl Chew) (11/13/89)
From article <4507@ast.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum): > In article <1684@bruce.OZ> cechew@bruce.OZ (Earl Chew) writes: >>#define WIFSIGNALED(__s) ((unsigned int) ((__s) - 1 & 0xffff) < 0xff) > > You may be right, but I find mine an awful lot clearer: > > #define WIFSIGNALED(--s) (_HIGH(__s) == 0 && __s != 0) > > Does anyone know if mine is ok? No it's not ok :-) #define WIFSIGNALED(__s) (_HIGH(__s) == 0 && (__s) != 0) I think that the standard does not impose any rules about macros (it does about functions implemented as macros) -- so you are ok. However, I feel that where there is an alternative, you are better off coding safe macros so that you won't get a surprise some time later. The point about clarity is valid but I think that safety is more important. Furthermore, the code is hidden within a macro and there's only 1 short line --- clarity is not a big issue in this case. Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 ARPA: cechew%bruce.cs.monash.oz.au@uunet.uu.net ACS : cechew@bruce.oz ----------------------------------------------------------------------