osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (11/08/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Thu, 7 Nov 85 Volume 12 : Issue 1
Today's Topics:
#include files and non-terminated statements
environment
Suggested ANSI C changes for international character set support (2 msgs)
----------------------------------------------------------------------
Date: Fri, 1 Nov 85 16:02:18 est
From: allegra!phri!roy (Roy Smith)
Subject: #include files and non-terminated statements
To: allegra!cbosgd!std-c
Background-Info: Vax-11/750, Unix 4.2bsd
I just got an interesting error. I have a header file which
defines some structures. I forgot the ";" at the end of the last one which
caused the C compiler to generate some very confusing error messages on the
line right after the #include directive.
Is it reasonable to have the compiler generate an error (or at
least a warning) if an included file ends in the middle of a statement?
[ Unless someone finds this addressed in the proposed (draft) standard,
please limit your replies to phri!roy. --Mod-- ]
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Thu, 7 Nov 85 09:01:01 est
From: pegasus!hansen
Subject: environment
To: std-c@cbosgd
Michael Gersten writes:
< As long as things are being improved in the standard, lets fix the
< environment:
<
< getenv()--return a string
< addenv()--add a string
< firstenv()--
< nextenv()-- these 2 will step through the entire environment
< clrenv()--delete the entire environment
< delenv()--delete one item from the environment
System Vr2 has added putenv(3) already. Something should be standarized
regarding others, however. Most are trivial to write, but why should
everybody reinvent the wheel every time. I'm not convinced that
firstenv()/nextenv() are worth standardizing on. Possible implementations of
the missing routines follow.
Tony Hansen
ihnp4!pegasus!hansen
extern char **environ;
/* clear out the environment. do no garbage collection */
clrenv()
{
*environ = (char *) 0;
}
/* delete "var=" from environment. do no garbage collection */
delenv(var)
char *var;
{
register char **lenv;
register int len;
if (var) /* look for "var=" in environ[] */
for (lenv = environ, len = strlen(var); *lenv; lenv++)
if ((*lenv[len] == '=') &&
(strncmp(*lenv, var, len) == 0))
{ /* move others up */
register char **lenv1 = lenv + 1;
while (*lenv++ = *lenv1++) ;
return;
}
return;
}
static char **localenviron;
/* return the first item in the environment */
char *firstenv()
{
return *(localenviron = environ);
}
/* return the next item in the environment */
char *nextenv()
{
return *++localenviron;
}
------------------------------
Date: Tue, 29 Oct 85 09:45:39 est
From: packard!topaz!harvard!wjh12!teddy!panda!jpn (John P. Nelson)
Subject: Suggested ANSI C changes for international character set support
To: std-c@cbosgd
>From: ihnp4!l5!gnu (John Gilmore)
>
>I see no reason not to make
>
>float string[] = "abc";
>
>assign the values 97., 98., and 99.
I HOPE it never comes to this. What a kludge!
I suspect that strings should remain arrays of CHAR, and if a particular
implementation needs to change the representation of CHAR to handle an
an international character set, then it will.
A char is an abstract quantity, defined to hold a displayable (or
non-displayable) character. Unfortunately, many people have used it
synonomously with "byte". I would rather see a new type "byte" be added
which is the smallest addressible store, and have char continue to represent
the amount of store necessary to represent a character. Adding "short"
strings is a true hacker's solution!
>expressions: how do you make "short" character strings instead of
>"char" character strings, or indicate that '%' means a short '%' rather
>than a char '%'? (replace % with your favorite Chinese glyph.)
The constant '%' is ALREADY of type INT not type CHAR!!
------------------------------
Date: Wed, 30 Oct 85 01:34:45 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: Suggested ANSI C changes for international character set support
To: std-c@cbosgd
>Date: Mon, 21 Oct 85 17:09:31 PDT
>From: ihnp4!l5!gnu (John Gilmore)
>Subject: Re: Suggested ANSI C changes for international character set support
>
>There is also the question of what to do about character constants in
>expressions: how do you make "short" character strings instead of
>"char" character strings, or indicate that '%' means a short '%' rather
>than a char '%'? (replace % with your favorite Chinese glyph.)
The mechanism exists. Use type-casting: (short) '%', etc.
>There is a slight wrinkle in saying that "abc" is equivalent to {'a',
>'b', 'c'}. In a 16-bit character set, 'a' must be the first
>*character* that appears after the ", not just the first *byte*. C
>compilers which are written assuming in 8-bit input characters (and
>which support strings > 8 bits) must run their strings thru a
>conversion routine to get long values for internal use. ...
There are a number of programs that assume "abc" means what it
means, which may break if the world changes about them.
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
------------------------------
End of mod.std.c Digest - Thu, 7 Nov 85 17:25:39 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.