osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/06/85)
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@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@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@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@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@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@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above.