osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (09/22/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Sun, 22 Sep 85 Volume 10 : Issue 5
Today's Topics:
C.3.3.4: encouraging robust coding
D.10.4.4: onexit
question on mktemp("/tmp/unbnewsXXXXXX")
variable arguments question
----------------------------------------------------------------------
Date: Thu, 19 Sep 85 12:31:08 EDT
From: seismo!elsie!ado
Subject: C.3.3.4: encouraging robust coding
To: std-c@cbosgd
The standard bearers might consider changing the example in section C.3.3.4
that reads:
extern void *alloc();
double *dp = alloc(sizeof(double));
to read:
extern void *alloc();
double *dp = alloc(sizeof *dp);
so as to encourage folks to write robust code.
(Why is the second example more robust than the first? Well, suppose
that at a later date someone decides to change the type of "dp" from "double"
to "long double". They might get sloppy in the first case and change the
code to
long double *dp = alloc(sizeof(double));
which will almost surely create mysterious errors. Whereas the same change to
the second example:
long double *dp = alloc(sizeof *dp);
would work.)
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
------------------------------
Date: Thu, 19 Sep 85 12:30:55 EDT
From: seismo!elsie!ado
Subject: D.10.4.4: onexit
To: std-c@cbosgd
In previous drafts of the standard, onexit returned a function pointer.
In the April draft:
Returns
The onexit function returns a value that compares uneual to zero
if the registration succeeds.
This being so, some consistency can be introduced into the scheme of things
by changing the type of the value returned by onexit to "int", and by changing
the above section to read
Returns
The onexit function returns non-zero if the operation fails.
It's also possible, of course, to define "onexit" this way:
int onexit(void (*func)(void));
and entirely eliminate the need for "onexit_t".
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
------------------------------
Date: Thu, 19 Sep 85 12:31:40 EDT
From: seismo!elsie!ado
Subject: question on mktemp("/tmp/unbnewsXXXXXX")
To: std-c@cbosgd
Here's a line of code from the 2.10.3 news version of "unbatch.c":
filename = mktemp("/tmp/unbnewsXXXXXX");
where mktemp replaces the X's with other characters and returns a pointer to
its argument.
Now the above isn't guaranteed to work under the draft standard, since
"/tmp/unbnewsXXXXXX" may be made read-only.
My question: how do you change the above line to guarantee it will work?
In particular, can the "volatile" keyword be introduced into the above
line to do the trick? (If not, should there be a way?)
(I trust folks won't get sidetracked into debates about "mktemp" versus
"tmpnam". The real question is: how do you arrange to make string constants
writeable in situations like the above one?)
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
------------------------------
Date: Mon, 16 Sep 85 17:34:36 EDT
From: Doug Gwyn <gwyn@BRL.ARPA>
Subject: variable arguments question
To: cbosgd!std-c@LOCAL.Berkeley
I have a question about the current ANSI X3J11 C rules concerning
variable argument lists for functions. Suppose I have the following
source code:
void func( int, ... ); /* from some header file */
void test()
{
func( 1 ); /* I think this is legal */
}
void func( i ) /* "line A" */
int i;
{
do_something_with( i );
}
The question is, is "line A" correct in this case, where I do not
need to deal with the optional arguments (since I know that I
will have none in this specific case), or is it necessary to
declare the function as:
void func( i, ... ) /* "alternate line A" */
int i;
{
do_something_with( i );
}
? My reading of the C Information Bulletin X3J11/85-045 is that
in any case I do not need to invoke the "stdargs" mechanism,
which is only required if I were to try to access the optional
arguments. (I would appreciate confirmation of this, too.)
This is actually a rather important question, because the IEEE P1003
(Portable Operating System Environment) draft standard has just been
amended to declare signal-handling functions to be of type:
void func( int, ... )
and I am concerned that signal handler definitions in portable code
might have to be written differently from current practice. I hope
that this is not the case, but have been unable to determine the
answer from the X3J11 document.
------------------------------
End of mod.std.c Digest - Sun, 22 Sep 85 11:18:00 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.