osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/30/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c> mod.std.c Digest Wed, 29 May 85 Volume 6 : Issue 14 Today's Topics: concatenation Pointer math and ints string literals structure tags ---------------------------------------------------------------------- Date: Sun, 26 May 85 16:37:12 edt From: decvax!duke!idis!george Subject: concatenation To: mcnc!duke!cbosgd!std-c Here is some additional elaboration on my suggestion concerning concatenation. (modified from draft 85-008) string-literal: unit-string-literal string-literal unit-string-literal string-literal character-constant Use of a multi-character character constant in this context specifies undefined behavior. Examples: #define BELL '\a' putchar(BELL) ; printf("" BELL) ; printf("error message\n" BELL BELL) ; #define SO '\16' #define SI '\17' printf("%s", "example: " SO "shifted out" SI " shifted in\n") ; In combination with the pre-processor, there is mnemonic benefit. Also, since a character constant could be converted to a string by preceding it by a pair of quotes (e.g. "" BELL), there would be no need for duplicate definitions as in Larry Rosler's example from mod.std.c volume 3 issue 9. > #define Esc '\033' > > or > > #define ESC "\033" A standard header file, "chars.h", could be created with appropriate definitions. This would obsolete escapes such as '\t' and '\a'. It would probably be useful to retain the old escapes, but perhaps '\a' would be unnecessary. George Rosenberg duke!mcnc!idis!george decvax!idis!george ------------------------------ Date: 26 May 85 14:41:05 CDT (Sun) From: plus5!hokey (Hokey) Subject: Pointer math and ints In article <939@homxa.UUCP> ico!spence (Spencer Rugaber) writes: > > On the subject of pointer subtraction, K&R is misleading. > ((&a[1] - &a[0]) / sizeof( a[0] )) would compute one object "separating > the pointed-to objects" when in fact the two objects are adjacent. > It also has the problem of potentially indicating a negative number of > intervening objects. The proposed definition provides more information > and is more precise. I see no problem. The two objects are adjacent, and the amount of space needed to store the object in between the two points is one object's worth. I can also see that a negative number would be OK. The issue of addresses of contiguous objects is, I believe, clearly spelled out in K&R (I suspect the same is true for the proposed standard). I agree that the proposed standard is clearer and more precise when describing pointer subtraction. I just want to see the part about the result being implementation-specific changed to be an int. If this is *really* a bad idea, then the people who choose to implement this result in something larger than an int should provide the means to warn people, preferrably by checking the type of the actual parameters against the formals. ------------------------------ Date: 26 May 85 14:56:57 CDT (Sun) From: plus5!hokey (Hokey) Subject: string literals In article <940@homxa.UUCP> Gary Ansok writes: > >printf("string" '\n'); /* would become printf("string\n"); */ >printf('>' "message"); /* he wants printf(">message"); */ > >... I think this fits in well with the string concatenation >already added, but it fits into the category of "Nice idea, but not >worth the trouble to implement" since you can use double quotes instead >of singles and get the desired effect (at the cost of a null byte). >Or is there a situation where the single quotes are needed? Think about sprintf instead, and what would happen if you wanted to do a strlen() on the result if that null byte was floating around in the buffer. ------------------------------ Date: Fri, 24 May 85 14:32:19 EDT From: ihnp4!seismo!harvard!kosower Subject: structure tags To: homxa!osd7 I don't know what the proposed standard says about this example, but K&R does state that structure tags are separate from other identifiers. I certainly hope the new standard won't change that... As far as pointers to undeclared structures are concerned, it is certainly OK by K&R; there is no requirement that the structure be defined by the end of the compilation unit (of course, this means you can only pass the pointer around, or dereference it through casts). In fact, I believe this is FEATURE; it allows compilation units to handle data (as an "object") without having to know the structure of its contents. Thus, the structure tag might be defined only in one source module, while usage (e.g. "struct tag *p") might appear everywhere. David. ------------------------------ End of mod.std.c Digest - Wed, 29 May 85 18:17:03 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.