mod.std.c Digest V6#13

[Orlando Sotomayor-Diaz]

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Wed, 29 May 85       Volume 6 : Issue  13 

Today's Topics:
                              Extensions
                               limits.h
                              type void
----------------------------------------------------------------------

Date: 28 May 1985   9:50 EDT
From: a.reed at cbosgd.ATT.UUCP
Subject: Extensions
To: std-c at cbosgd

Since the standard will allow compiler extensions, it needs
a way to keep extensions from breaking code that conforms to the
standard. I think that the best way to do this is an "extension"
statement that might work as follows:

Every program which uses an extension to standard C shall include a
statement of the form "extension xtn_name;", where xtn_name is the name
of the extension. A program without extension statements will be compiled
in accordance with standard, unextended C.  Words reserved in the
implementation of any specific extension shall not be treated as reserved
unless an extension statement specifying the use of that extension is
included in the program.

For example, let "cplspls" be the name of the extension from standard C
to C++. If a compiler which accepts both standard C and C++ finds in a
program the statement

extension cplspls;

it will compile this program according to C++.  On the other hand, a
program without extension statements will be compiled as a standard C
program, with no special meaning attached to words which happen to be
reserved in the implementation of C++.

The upper-case equivalent of the name of each implemented extension shall
be pre-defined in the compiler's pre-processor.

For example, let "sepioadr" be the name of an extension supporting
an "io" modifier for ports located on an Intel-style separate i/o address
space. The following header fragment might be found in programs using
this extension:

#ifdef SEPIOADR
extension sepioadr;
#else
#define io volatile
#endif

What do you think?
			Adam Reed
			AT&T Information Systems
			ihnp4!npois!adam

------------------------------

Date: 24 May 85 12:07:49 EDT (Fri)
From: Craig Partridge <ucbvax!craig at loki.ARPA>
Subject: limits.h
To: cbosgd!std-c at BERKELEY

    I was re-reading the standard today and noticed a minor problem
with the definition of <limits.h>.  What happens if there is no limit;
when there is no need for a limits value?  The most obvious example,
though I hate to bring it up because it will cause this issue to flame
yet again, is identifier names.  On compilers using flexnames the
constant EXTERNAL_NAME_LENGTH will have no meaning.  What does one
do with it?  Set it to -1, or not define it?  I think we ought to have
some answer to this issue -- code may be #ifdef'ed based on some of these
values, and certain ones may be superfluous or worse, misleading, on some
compilers.  I admit that at this point I can identify only the name
length definitions and the maximum chars on a line definition as
potentially superfluous (and I personally wouldn't want anyone #ifdef'ing
on these constraints), but, who knows, it may be that for some reason other
constants turn out to be superfluous in odd situations.


    As an off the cuff suggestion, I suggest not defining the constant.
Thus

#ifdef EXTERNAL_NAME_LENGTH

would suffice as a test to see if my compiler placed a limit on external
name lengths.  I'm amenable to better ideas.


Craig Partridge
craig at bbn-loki (ARPA)
craig%loki.arpa at csnet-relay (CSNET)
{decvax,ihnp4,wjh12}!bbncca!craig (USENET)

P.S. My copy of the standard is as of February 11th, so it may be that
this problem was fixed...

------------------------------

Date: Thu, 23 May 85 19:57:30 edt
From: wanginst!mckeeman at bbncca <mckeeman at wanginst.UUCP>
Subject: type void
To: ima!cbosgd!mark at bbncca.uucp

My best guess for what is meant by type void is that it IS a type (like the
standard says) and that it has NO values.  I have a reason to want the below
to work and assume that treating void as a first-class-type would not cause
any existing code to break.  Comments?

>From my reading of the February 11 standard the following should work.

It does not on 4.2.

void a() {return (void) 1;}
main(){
  void b;		/* a variable requiring no storage */
  int c;		/* ...how about &b  */
  b = a();		/* an assignment generating no store */
  if (b == (void) c)	/* an always-false test */
    b = (void) c++;	/* only the increment gets done */
}

/s/ Bill McKeeman at WangInst, ...decvax!wanginst!mckeeman

------------------------------

End of mod.std.c Digest - Wed, 29 May 85 18:10:51 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.