Prototypes for macros?

[Evan Manning]

dan at kfw.COM (Dan Mick) writes:

>In article <1990May3.202403.10140 at laguna.ccsf.caltech.edu> gleeper at tybalt.caltech.edu (Evan Manning) writes:
>>I ran into an interesting situation yesterday playing with my brand
>>new Turbo C 2.0.  I was trying to use it with all warnings and errors
>>enabled, as I'd heard it claimed that this obviated all need for lint
>>(At my previous job I got quite attached to PC-Lint from Gimpel but now
>>it's my money so I thought I'd at least give Turbo a chance.)
>>
>>The problem emerged when I tried to use some functions (randomize &
>>random) which are defined as macros in the headers.  TC gave me a
>>'no prototype in scope' warning and then some other error message I
>>don't recall when I disabled the prototype warning.  All problems
>>vanished when I slavishly copied the definitions of the macros from
>>the header.
>>
>>Is it a bug?  Should macros have prototypes too?  Will I have to worry
>>about putchar et al?

>Erm...if you had included the header, there wouldn't have been a warning,
>since, after it was preprocessed, there would be no "function" randomize()
>or random() to complain about.

>#include <stdlib.h>

I guess I should have mentioned that I'm not a rank amateur.  All
appropriate headers were included (including time.h for seeding off
the time in randomize()) and these are the precise same headers needed
to avoid warnings after manually expanding macros.  My guess is that
Turbo is checking for prototypes *before* expanding macros.  Which
sounds wrong to me.  Has anybody encountered this before?

-- Evan

***************************************************************************
Your eyes are weary from staring at the CRT for so | Evan M. Manning
long.  You feel sleepy.  Notice how restful it is  |      is
to watch the cursor blink.  Close your eyes.  The  | gleeper at tybalt.caltech.edu
opinions stated above are yours.  You cannot       | manning at mars.jpl.nasa.gov
imagine why you ever felt otherwise.               |