[mod.std.c] mod.std.c Digest V5#2

osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (04/07/85)

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Sun,  7 Apr 85       Volume 5 : Issue   2 

Today's Topics:
                      floating-point remainder??
                    ftell/lseek is a magic cookie?
                           struct questions
                              unary plus
----------------------------------------------------------------------

Date: 6 Apr 85 20:53:17 CST (Sat)
From: ihnp4!utzoo!henry
Subject: floating-point remainder??
To: ihnp4!cbosgd!std-c

> In 4.2bsd's pcc, and I would guess many others, the operands of '%'
> can not be floating point.  Is this true in the new standard, or is the
> standard, by not saying otherwise, explicitly allowing '%' of reals?  I
> hope it is the latter, but I thought I'd ask.

The 11 Feb 1985 draft (and possibly earlier ones, but I don't have copies
on hand) says firmly that the operands of % must have integral type.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

------------------------------

Date: Wed, 3 Apr 85 23:52:24 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: ftell/lseek is a magic cookie?
To: std-c@cbosgd.ATT.UUCP

> If you are not supposed to know what the position given to lseek is,
> what is the procedure for locating a record in a fixed length record
> file.

sorry, 'fraid it's got to be:
	rewind(f)
	while (--nrec >= 0)
		fseek(f, recsize, SEEK_REL)
	fread the record.

Of course, if you don't mind it being non-portable to a few "less
important" systems, go ahead and seek to nrec*recsize.  I usually
do.  On other systems, there may be other idioms.  If you are dead
serious about being both efficient and ultra-portable, encapsulate
this problem as recseek(f, nrec, recsize).

	Joe Yao		hadron!jsdy@seismo.{ARPA,UUCP}

------------------------------

Date: Sat, 6 Apr 85 7:04:18 EST
From: Doug Gwyn (VLD/VMB) <ucbvax!gwyn@Brl-Vld.ARPA>
Subject: struct questions
To: cbosgd!std-c@BERKELEY

[ Draft mentioned is dated 2/11/85?  -Mod- ]

It is not 100% clear to me that the latest draft standard
permits

typedef struct foo
	{
	struct bar	*pbar;
	};
typedef struct bar
	{
	struct foo	*pfoo;
	};

without prepending the declaration

struct bar;

  It is even less clear whether the following initialization
is legal:

struct list
	{
	struct list	*next;	/* yes, this is allowed */
	};
struct list head = { &head };	/* ??? */

  I would appreciate clarification on these points.

------------------------------

Date: 6 Apr 85 20:53:08 CST (Sat)
From: ihnp4!utzoo!henry
Subject: unary plus
To: ihnp4!cbosgd!std-c

> Why is this [unary plus] added?  I can guess: it is a matter of
> consistency and completeness.  [Grumble.]

My understanding is that one other motivation, apart from notions of
cleanliness and symmetry, was that "+0.5e2" (for example) is legal when
read from input but not in source.  All the formatted-number i/o stuff
accepts either sign; it seems a bit silly that you have to strip the
pluses off if you decide to put the numbers in a table in the source
instead.

There are some other arguments that I don't think much of, such as
easing automatic translation of (gak) Fortran, and the peculiar use
of unary plus to force order of evaluation.

The above is intended as an explanation of perceived motives, not as
a statement of passionate support for unary plus.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

------------------------------

End of mod.std.c Digest - Sun,  7 Apr 85 09:10:49 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.