Re: Obfuscation devices (was Name Space Pollution: using macros ...)

From: Dave Vandervies (dj3vande_at_csclub.uwaterloo.ca)
Date: 10/14/03 

Date: Tue, 14 Oct 2003 20:50:37 +0000 (UTC)

In article <Pine.LNX.4.58-035.0310141615590.14355@unix48.andrew.cmu.edu>,
Arthur J. O'Dwyer <ajo@nospam.andrew.cmu.edu> wrote:
>
>On Tue, 14 Oct 2003, Ben Pfaff wrote:

>> Follow along, please: that's the point. Dan claimed that
>> #define'ing a keyword is portable as long as it is done after
>> header inclusion. I said it's not and showed an example.
>
>Well, really Dan only said that
>
>#define int double
>
>was portable (as long as, etc). So you could have given a
>counterexample to *that* statement, instead of the general
>case (which I'm sure Dan considered). Can constant expressions
>contain casts? In that case,
>
>#define NULL ((void*)((int)1-1))
>
>could break Dan's *actual* suggestion, as well. Or even
>
>#define NULL ((void *)(sizeof(int)-sizeof(int)))
>
>which I *know* is a correct definition of NULL (don't I?).

I don't see the #define that Dan suggested breaking this. After expanding
the "int" macro, it would become:
#define NULL ((void *)(sizeof(double)-sizeof(double)))
sizeof(double) will have the same value (of type size_t) both places it
occurs, so this is still casting an integer constant expression with
value 0 to void *, and is no less a valid definition of NULL if "int"
means double than if "int" means int.

Can an implementation legally define macros that rely on int really
meaning int? I think your first example is valid, and in this case
Dan's #define will break code that uses it.

Alternately, either the programmer isn't allowed to define preprocessor
macros with the same names as type names (perhaps all keywords?), or the
implementation really should do something like "typedef void *__voidptr"
and use a cast to __voidptr in NULL (and do something similar for other
type names it uses in macros) instead of using type names that the
programmer is allowed to mangle.

dave 

-- 
Dave Vandervies                                  dj3vande@csclub.uwaterloo.ca
Uh-huh.  And a criticism of computers is that they manipulate numbers without
feeling, and a criticism of humans is that they are bipeds that eat and make
little bipeds.                                 --Peter Seebach in comp.lang.c

Relevant Pages

  • Re: S-expr form of C
    ... rpw3@xxxxxxxx (Rob Warnock) writes: ... and have macros defined to build these CLOS ... to ground such an effort firmly in some concrete syntax which *can* ... (let ((av int) ...
    (comp.lang.lisp)
  • Re: [PATCH] WARN_ONCE(): use bool for boolean flag
    ... Yes, it could (as long as either it is converted back to int in the return of the macro, or all users do not care about the macro's return type). ... text data bss dec hex filename ... conditionals it drops it by another 84 bytes. ... Besides, the unlikelyall these macros end with does a double negation, meaning even if it is an int, it will be either 0 or 1 into likely). ...
    (Linux-Kernel)
  • Type name style was Re: rolling dice
    ... } DICEROLL; ... I strongly advocate the use of ALL CAPS for macros and for macros only. ...
    (comp.lang.c)
  • Re: Using multiple defines!
    ... int *A2, ... //aGMI declared in header ... Leave ALL_UPPERCASE for macros and use only that for all macros. ... wanted to declare everything at the top with define statements. ...
    (microsoft.public.vc.language)
  • Re: [KJ] Re: [PATCH] drivers/isdn/hisax: ARRAY_SIZE instead of sizeof
    ... are assigned to preprocessor macros. ... int __init ... static void ...
    (Linux-Kernel)