osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (03/23/86)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Sun, 23 Mar 86 Volume 14 : Issue 1
Today's Topics:
"address" format for printf?
__LINE__
C Standards
remainder on floats
declaring function prototypes
Forward-declaring static variables
----------------------------------------------------------------------
Date: Sat, 22 Feb 86 13:20:10 est
From: allegra!phri!roy (Roy Smith)
Subject: "address" format for printf?
To:
Whenever I want to print an address in a C program (typically as
part of a debugging display), I never know whether to use %o or %x in the
printf format specifier. Back in the pdp-11 days it was easy; you used
octal. Now, with Vaxen and 68000's and zillions of other machines running
Unix, you might want to use hex. What is actually needed is a %a which
says print this number in whatever radix is appropriate for the machine you
are running on. Let's do for addresses what %g did for floating point!
Of course, the alternatives need not be limited to octal or hex.
If some extremely demented person were to dig up an old IBM-650 and try to
port Unix to it, addresses would have to be done in decimal (I think).
------------------------------
Date: Thu, 27 Feb 86 16:52:58 EST
From: seismo!elsie!ado
Subject: __LINE__
To: cbosgd!std-c
My April 30, 1985 Draft standard has a "conceptual model" on page 5 that
breaks language processing into these successive phases (among others):
. . .
2. Each instance of a new-line character and an immediately
preceding baclslash character is deleted, splicing
physical source lines to form logical source lines.
. . .
5. The source is preprocessed. . .
Later, in discussing the preprocessor, the standard reads:
. . .The line number of the current source line is one greater than
the number of new-line characters read while processing the source
file to the current token. . .The predefined macro name __LINE__
has the value of the line number of the current source line
(a decimal constant). . .
It's unclear (to me, at least) whether the new-line characters that are
counted in determining __LINE__ are those in the physical source lines
(seen in conceptual phase 2) or those in the logical source lines
(seen in conceptual phase 5, the preprocessing phase). I'd imagine that
having __LINE__ be a physical source line number would be preferable,
but how can that be accomplished without breaking down barriers between
conceptual phases?
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
------------------------------
Date: Wed, 12 Feb 86 09:35:27 pst
From: uw-beaver!ssc-vax!zadco@ihnp4.uucp (Rick Fairfield)
Subject: C Standards
To: cbosgd!mark@ihnp4.uucp
I need to find a set of standards (formal or otherwise) for programming
in C. Does anyone have or know of any such standard?
thanx,
Rick Fairfield
Boeing Aerospace
206-773-1004
...ssc-vax!zadco
------------------------------
Date: Wed, 22 Jan 86 15:16:07 EST
From: Doug Gwyn <gwyn@BRL.ARPA>
Subject: remainder on floats
To: std-c%cbosgd.uucp@BRL-TGR.ARPA
> I was surprised to discover that the C language does not define the
> remainder operation (%) on floats. It's certainly clear that this is
> useful (ever do argument reduction for transcendentals?) and there
> are good definitions of it, e.g. in the IEEE float spec. Is this
> just a historical problem (e.g. the PDP-11 didn't have the instruction
> so it's not in C) and is this likely to get fixed by the standard?
> I too once wondered about this until Ron pointed out to me
> that there IS no remainder when you divide one real number
> by another.
Last time I looked, X3J11 included the fmod() function,
which is probably what you want. If the compiler is able
to generate an in-line expansion for this rather than a
function call, I suppose that would be permitted.
------------------------------
Date: Fri, 7 Mar 86 00:42:20 PST
From: jon@csvax.caltech.edu (Jonathan P. Leech)
Subject: declaring function prototypes
To: cbosgd!std-c
An off-the-wall proposal: C++ allows functions with the same name
but different arguments; i.e.
pow(double,int) and
pow(int,int)
can be distinguished by their argument types. How about adding a
capability like this to the pre-processor, with the difference that
the only criteria for overloading a #define is the NUMBER of
arguments to a macro; i.e.
#define SUM(a,b) ((a) + (b))
#define SUM(a,b,c) (SUM(a,b) + (c))
This just occured to me while I was trying to come up with an easy
way of declaring function prototypes so I could put them in now to be
ignored but by changing one #define when ANSI compilers are finally
available have them operational; something like
#ifdef ANSI
#define DECL(func) func()
#define DECL(func,a1) func(a1)
#define DECL(func,a1,a2) func(a1,a2)
/* etc. */
#else
#define DECL(func) func()
#define DECL(func,a1) func()
#define DECL(func,a1,a2) func()
/* etc. */
#endif
extern double DECL(sqrt, double);
extern FILE * DECL(freopen, const char *, const char *, FILE *);
Of course this isn't possible with current compilers ('argument
mismatch'), but it might be nice to have this capability anyway. As
far as I can tell it won't break existing code.
-- Jon Leech (jon@csvax.caltech.edu)
__@/
------------------------------
Date: Wed, 19 Mar 86 00:40:48 pst
From: Nathan C. Myers <hp-pcd!orstcs!nathan>
Subject: Forward-declaring static variables
To: cbosgd!std-c
The following has been a portability problem in C; I don't see it addressed
in the draft standard. Suppose you want to initialize a state table with
circular references, and want the table entries declared static.
For example:
struct entry { struct entry *next; int i; };
static struct entry e1 = { &e2, 0 };
static struct entry e2 = { &e1, 1 };
The first initialization will fail, as e2 hasn't been seen
yet. We need to "forward" declare e2 without defining it. But how?
Putting an "extern" on would prevent definition, but would conflict
with the "static" later on (at least according to the ANSI C draft).
Calling them static in the forward-declaration would define them too.
Do we need a special-case here (e.g. static overrides earlier extern)?
If so, the standard should say so -- otherwise implementors will
make their own merry mess of it.
Nathan C. Myers hplabs!hp-pcd!orstcs!nathan nathan@oregon-state
------------------------------
End of mod.std.c Digest - Sun, 23 Mar 86 11:10:03 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.