mod.std.c Digest V7#5 (repeat)

[Orlando Sotomayor-Diaz]

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


mod.std.c Digest            Mon, 24 Jun 85       Volume 7 : Issue   5 

Today's Topics:
                        Comment to end of line
                        Miscellaneous comments
                    Pointer math, sizeof, and ints
                 UNIX/WORLD note on & operator change
----------------------------------------------------------------------

Date: Thu, 20 Jun 85 11:32:15 edt
From: Arnold Robbins <gatech!arnold>
Subject: Comment to end of line
To: std-c at cbosgd.UUCP

This has been discussed before on net.lang.c, but I don't remember seeing it
in mod.std.c.  Many languages are going with the comment style that uses
a delimiter and goes to the end of a line. Ada is the most recent example,
while the Unix shells, Ratfor, Efl and Make all use the # sign, which
of course is already used by the C language.

C++ allows the conventional /* ... */, but also uses // as the here-to-
end-of-line type.  Someone in net.lang.c pointed out that // could
possibly break an existing program. e.g.

	x = y //* divide y by z */ z;     

I would like to suggest that the standard incorporate this style of comment,
and let :: be the delimiter.  There is no place in K&R C that I can think
of where two adjacent colons are legal, so

	x = y ();	:: call y() and assign return value to x

would work.  Another alternative would be the @ sign, since C does not
use the @ sign at all.  I would suggest $, but some compilers allow $
as a letter in identifiers, so I'll leave $ alone.

These two styles of comment can coexist well, and it also makes it easy
to comment out code with embedded comments in it (yes, I know about using
#ifdef notdef ... #endif; nothing wrong with that, but :: is an alternative).

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

Date: Fri, 21 Jun 85 09:17:34 pdt
From: allegra!sdcrdcf!psivax!friesen (Stanley Friesen)
Subject: Miscellaneous comments
To: sdcrdcf!research!cbosgd!std-c

	Well, since I have *finally* received a copy of the Draft
Standard, I will now essay to make a few remarks. Some of these may
have already been commented on, but here goes.

	The opening sentence of Section B.2.4.1 is ambiguous as
written, I think it should be rewritten to parallel the opening
sentence of the following section(B.2.4.2). This is a minor nit,
since the the matter is disambiguated later in the document.

	As I understand Section C.5.2 (Type specifiers), it
disallows a declaration of "long float", which I think should
be allowed as an equivalent to "double".  This is clearly stated
on pg 93 of K&R. and I see no good reason to depart from the
definition of the language in K&R on this point.

	Also, why is the library include file containing the
defines for handling variable parameter lists called *stdarg.h*
instead of "varargs.h"? Is this because the UNIX naming is not
very widespread or what? If this is not the case, it seems to
me that changing its name is a poor decision.
-- 

				Sarima (Stanley Friesen)

{trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen
or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen

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

Date: Fri, 21 Jun 85 20:36:24 pdt
From: seismo!dual!qantel!vlsvax1!zehntel!tektronix!reed!isonvax!vrs
Subject: Pointer math, sizeof, and ints
To: reed!tektronix!zehntel!vlsvax1!qantel!dual!lll-crg!gymble!umcp-cs!seismo!cbosgd!std-c at gymble.ARPA

  I have followed with interest the discussion of the size of the result of
the subtraction of two pointers, and wondered at the lack of discussion of
the size of the result of 'sizeof'.  As has been pointed out before, this
affects machines based on both Intel and Motorola chips and probably some
esoteric hardware as well.

> Date: 17 May 85 20:10:13 CDT (Fri)
> From: plus5!hokey (Hokey)
> Subject: Pointer math and ints
> To: std-c at cbosgd
> 
> Changing the result from "an _int_" to "a signed integer (the size of
> which is implementation defined)" breaks existing code.

I agree.  I further agree that the bugs introduced by this change are
sometimes hard to detect.  I disagree that the standard should be changed.
My reasoning is that the affected programs are de-facto broken from a
portability perspective, and one objective of coding according to a standard
is certainly a guarantee of portability.

  I wonder -- is there any machine on which the difference of two pointers is
not a long?  Most of the machines used by people who complain about this have
int == long == 32 bits.  Is there an obvious advantage to ptr_diff_t and
sizeof_t over long?  This is consistent with the idea of avoiding the use of
int whenever possible in favor of short or long, and saves the introduction
of two new 'types'.  (The people with 'reasonable' hardware could even continue
their sloppy coding practices if they liked 8-)).  Please note that I don't
have any particular interest in the long vs ptr_diff_t decision going either
way (just asking), but I do feel strongly that the difference of two pointers
is not an int.  Please, please, world, think of an int as '16 or more bits'
and not '32 or more bits' for a couple more years!

One last thing -- does anybody care that the result of sizeof may be larger
than an unsigned, or did this get beaten to death elsewhere or before I
tuned in?

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

Date: Wed, 19 Jun 85 19:29:25 EDT
From: seismo!elsie!ado
Subject: UNIX/WORLD note on & operator change
To: std-c at cbosgd

An article in the July, 1985 issue of UNIX/WORLD magazine describes
a draft standard change in the use of the C language & operator; the
description refers to "time_t", which appears in a header file and is
the type of variables used with the "time" function (among other things):

	. . .what if the time_t is an array of ints to hold the time in
	microseconds?  Because the standard allows the compiler vendor to
	define any type to time_t, you cannot write a portable program that
	passed the address of an item defined with a supplied typedef.
	Since you don't necessarily know whether such items are arrays,
	the standard now allows you to use the & operator with array names
	and function names.

I'll ignore the issue of why it is that the standard allows the & operator
to be applied to both arrays and functions when the only problem (or rather,
the only problem described above) is with the & operator applied to arrays.
Instead, I'll fret about the fact that allowing the & operator to be applied to
arrays will NOT allow time_t to be typedefed to an array, since variables of
type time_t are returned by standard functions (the function "time" in
particular)--and functions are not allowed to return arrays.  Folks interested
in seeing the problem concretely can run these two lines:
	typedef int	time_t[2];
	extern time_t time();
through their favorite C compiler.

Of course, if functions are written so that only pointers to items of a given
type are passed as arguments or returned, then the described change to the &
operator can be of use.  (And if the standard is changed to allow functions to
return arrays, all bets are off.)
--
UNIX is an AT&T Bell Laboratories trademark.
UNIX/WORLD is not affiliated with AT&T Bell Laboratories or Western Electric.
[ Western Electric (RIP)? You mean AT&T Technologies. -- Mod -- ]
--
	UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie!ado at seismo.ARPA
	DEC, VAX and Elsie are Digital Equipment and Borden trademarks

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

End of mod.std.c Digest - Mon, 24 Jun 85 18:37:07 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.