G'Day Roy,
 
-=> Quoting Paul Edwards to Roy Mcneill <=-

Let me make it a bit easier to comprehend, Paul probably missed the bit 
where you noted that you're using BC4, Borland and the standard don't go in 
the same soup too well:)

 RM> #define  C#  271
 PE> #define xxx yyy
 PE> the xxx is an identifier.  An identifier is defined as a sequence 
 PE> of alpha + _ + digits, starting with a non-digit.  FREQ ANSI_C.*
The #define may have gone through, but within the code the '#' denotes the 
start of a macro( never used one though ), outside the code it is like Paul 
said.So while the compiler may not worry about the #define statement being 
wrong, it'll have a fit when you try to use that variable in the code.
 
 RM> _:
 
 RM> I've always been puzzled by the use of the leading underscore in C
 RM> programs. It's a standard character like a,b,c as far as the
 RM> compiler is concerned, but it appears at the front of some
 PE> ^^^^
 RM> constants and functions as if it has some magical significance.
 PE> ^^^^^^^^^^^^^^^^^^^^^^^
 RM> What is this significance?

 PE> There are no special constants or functions that start with _ that
 PE> I am aware of in the C standard.
True, but in Borland there are..      
The '_' seems to be used in function names that may be called on by their
standard functions.
EG: strcpy() will use far addresses normally, so i assume it will call on 
_fstrpy(), same with _graphsetmem(), graphinit() will call that, but you can 
call it yourself if you want to manipulate the graphics' memory alocation. 
Why i would want to question the compiler on it's memory allocation scheme is 
another question :-)
As for the variables i reckon the same applies.

  L8r Frank (fadam{at}ozemail.com.au).
  
___ Blue Wave/DOS v2.21

--- Maximus 3.00