mod.std.c Digest V6#14

[Orlando Sotomayor-Diaz]

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 at 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 at 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 at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.