[comp.lang.c] Undelivered mail

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Re: ANSI C idea: structure literals (and short constants)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 4501
          for SXJVK@ALASKA; Fri, 11 Mar 88 13:04 AST
Received: by UWAVM (Mailer X1.25) id 3101; Fri, 11 Mar 88 14:03:16 PST
Date:         Wed, 9 Mar 88 17:05:26 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Alan J Rosenthal <flaps@dgp.toronto.EDU>
Subject:      Re: Re: ANSI C idea: structure literals (and short constants)
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>


decot@hpisod2.HP.COM (Dave Decot) wrote:
>The problem of deciding what their type is solved for now (and possibly
>always) by stating in the standard that such syntax has no inherent type
>and must be cast or assigned to the desired type.

henry@utzoo.uucp (Henry Spencer) responded:
>[expletive deleted]  Speaking as a user and an implementor, this is an
>abortion if there ever was one.

decot@hpisod2.HP.COM (Dave Decot) responded:
>Thank you for the feedback.  But I wonder if you would be so kind as to
>elaborate on this comment ...
>I'm afraid it is not clear to me that all usages of structure constants
>are self-explanatory.

They're not, but the point is that this is a totally new meaning for a
cast.  Usually, a cast is a unary operator.  Here, it's part of the
description, like a declaration.  To be specific: "(int)f" is an
expression that gets an int-ish value for the floating expression f.
It doesn't change f.  In your proposal, (struct a){...} and (struct b){...}
imply different values for {...}.  This is very inconsistent, even
worse than the inconsistencies between casting pointers and casting
numerical types.  Also, your (struct ..) cast will produce an lvalue,
which is also a big inconsistency.

I think it's clear that a new syntax, such as Karl Heuer's, is required.
I would prefer a symbol rather than a keyword, but that's just me.
(But: how about any of backquote, dollar, at (@), or right square bracket?
Perhaps unary comma?  Perhaps if the `&' is immediately followed by an
opening brace?)

ajr
--
If you had eternal life, would you be able to say all the integers?

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Are the criteria for Unix and PC compilers different?

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 4971
          for SXJVK@ALASKA; Fri, 11 Mar 88 14:24 AST
Received: by UWAVM (Mailer X1.25) id 3283; Fri, 11 Mar 88 15:24:19 PST
Date:         Wed, 9 Mar 88 19:49:39 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Ray Butterworth <rbutterworth@watmath.waterloo.EDU>
Subject:      Re: Are the criteria for Unix and PC compilers different?
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <22314ad9@ralf.home>, Ralf.Brown@B.GP.CS.CMU.EDU writes:
> In article <1106@silver.bacs.indiana.edu>, backstro@silver.bacs.indiana.edu
(Dave White) writes:
> }When will they
> }realize that some of us really want the option of using 32-bit ints to
> }port Unix-born code?
>
> #define int long
> Need I say more?

Yes.

I think "Unix-born" is a euphemism for "badly written" or "non-portable".

Code that assumes that "int" is 32 bits is usually written because
the programmer was lazy.  By making everything "int" he can avoid
having to make many declarations and having to include header files.

In particular, instead of having code like:
    extern int func1();
    extern int x;
    int func2(a) int a; { blah; blah; }
he will probably have:
    extern x;
    func2(a) { blah; blah; }
or maybe even
    x;
    func2(a) { blah; blah; }

"#define int long" won't help much with this code.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 5037
          for SXJVK@ALASKA; Fri, 11 Mar 88 14:38 AST
Received: by UWAVM (Mailer X1.25) id 3334; Fri, 11 Mar 88 15:36:27 PST
Date:         Thu, 10 Mar 88 03:51:24 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Daniel A. Glasser" <dag@chinet.uucp>
Subject:      Re: Header problems
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Okay, I've now been flamed and roasted via mail, news and even on the
phone for my posting about NULL and 0.

If it were not for noisy and slow connections between the system I
do my posting from and where I actually am, I would have written
that to be the safest, you must cast NULL whenever you use it in a
call.  It was my recollection, and I did not have my K&R handy to
check it out when I posted my message, that the C specification in
K&R stated that when pointers to different objects had different
representations, all pointers were passed in the "universal" pointer
representation, just as char is promoted to int, float to double,
so would (foo *) be promoted to the equivilent of (void *), and then
moved back into a (foo *) representation when used at the other end.
Having delt with compilers that did this, I assumed that the language
had this orthoginality.  I'm sorry, I aplogise to everyone who's
life I have ruined with my posting.


I made my posting not out of a lust for power, but because in my
everyday work, I get about 3 calls a week passed to me from the
tech. support people where I work from customers who are porting
VAX unix code to the Atari ST using our compiler where ints are
16 bits, pointers 32 bits, and they often INSIST that K&R allows them
to use 0 or NULL without casts in function calls expecting pointers.
They get upset when I tell them that that is not the case.

If it makes you feel any better, I'll retract what I said.
However, the

    #ifndef ... #endif

or the

    #undef

should be used, and the EXPLICIT casting of any use of NULL in a parameter
list should be stressed.

<flame on>

Please note that of over 100 programs that I have gathered from the
network source groups, not one of them that I have actually looked at
has cast NULL to any kind of pointer when using it in calls.  Not one!
Not even the GNU stuff that I've looked at.

In other words, though proper usage uses casts on NULL, common usage
does not.

<flame off>
--
        Daniel A. Glasser    dag@chinet.UUCP
    One of those things that goes "BUMP!!! (ouch!)" in the night.
 ...!att-ih!chinet!dag | ...!ihnp4!mwc!dag | ...!ihnp4!mwc!gorgon!dag

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 5172
          for SXJVK@ALASKA; Fri, 11 Mar 88 15:02 AST
Received: by UWAVM (Mailer X1.25) id 3419; Fri, 11 Mar 88 16:00:18 PST
Date:         Wed, 9 Mar 88 17:20:17 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Alan J Rosenthal <flaps@dgp.toronto.EDU>
Subject:      Re: Header problems
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>


Doug Gwyn <gwyn@brl.arpa> wrote about NULL, and said that the proper
definition of it is ``#define NULL 0''.

dag@chinet.UUCP (Daniel A. Glasser) wrote:
>Your use of NULL === 0 promotes unportable code ... [moralizing deleted]
>
>On machines were sizeof int != sizeof(void *), the above definition will
>not work on older style function calls (without prototypes) or in var-arg
>situations.  Requiring sizeof int == sizeof(void *) is not a viable
>solution...
>
>    #define    NULL    ((void *)0)
>On older compilers, replace 'void' with 'char'.  This allows the use of
>a short NULL representation when the compiler is smart enough to use it
>but forces passing of NULL in argument lists as a pointer sized object.

This doesn't require sizeof(int) == sizeof(void *).  The assumption is
that you always cast NULL before passing it.  Casting is still required
if NULL is defined as ((void *)0); you can't assume that all pointers
have the same size or representation.  Passing a pointer to void to a
routine that expects a pointer to struct gosh is as big a mistake as
passing an int to a routine that expects a pointer to struct gosh.

By the way, if you call f(0) where f expects a char *, the requirement
for it to work is not simply that sizeof(int) == sizeof(char *), but
also that (int)0 and (char *)0 have the same bit representation.

With respect to your phrase "a pointer sized object" - there is no such
thing in C.  There may happen to be such a thing in a particular
implementation of C due to hardware considerations.  (Obviously, it is
usually advantageous to represent all pointers in the same way (but not
always); therefore this is a common occurrence.)

ajr
--
If you had eternal life, would you be able to say all the integers?

rsalz@bbn.com (Rich Salz) (03/12/88)

In regard to all those BITNET lossage messages, i.e.:
 Subject:  Re: Header problems
 
 [Non-Deliverable:  User does not exist or has never logged on]
 
 Reply-To: Info-C@BRL.ARPA
 
 Received: From UWAVM(MAILER) by ALASKA with Jnet id 5037
           for SXJVK@ALASKA; Fri, 11 Mar 88 14:38 AST
 Received: by UWAVM (Mailer X1.25) id 3334; Fri, 11 Mar 88 15:36:27 PST
 Date:         Thu, 10 Mar 88 03:51:24 GMT
 Reply-To:     Info-C@BRL.ARPA
 Sender:       Info-C List <INFO-C@NDSUVM1>
 From:         "Daniel A. Glasser" <dag@chinet.uucp>
 Subject:      Re: Header problems
 Comments: To: info-c@brl-smoke.arpa
 To:           Vic Kapella <SXJVK@ALASKA>
 
 ....

I sent a note to info-c-request@brl.arpa, info-c@ndsuvm1.bitnet,
and sxjvk@alaska.bitnet.  Feel free to roast the BITNET sites,
but don't flame at info-c-request too much.

I am curious, tho, if the user does not exit or has never logged on,
how the !@#$ they managed to subscribe to the info-c list?
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  SUN Env. Vars.

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 5915
          for SXJVK@ALASKA; Fri, 11 Mar 88 17:46 AST
Received: by UWAVM (Mailer X1.25) id 3816; Fri, 11 Mar 88 18:43:38 PST
Date:         Thu, 10 Mar 88 17:08:55 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Stuart A. Werbner" <stu@linus.uucp>
Subject:      SUN Env. Vars.
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>


    Hello fellow SUN/UNIX enthusiasts.

    Could someone please mail me a list of all environment variables
    recognized by the Sun 3.x Operating System (and resident commands
    and utilities).  If not, could someone please tell me how to
    (easily) find such a list.

    Thank you.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Why I won't use ANSI C

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 5993
          for SXJVK@ALASKA; Fri, 11 Mar 88 17:53 AST
Received: by UWAVM (Mailer X1.25) id 3930; Fri, 11 Mar 88 18:50:46 PST
Date:         Wed, 9 Mar 88 18:31:07 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Ray Dunn <ray@micomvax.uucp>
Subject:      Re: Why I won't use ANSI C
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <671@cresswell.quintus.UUCP> Richard A. O'Keefe writes:
>At the last count, I have made 8 attempts to send e-mail to Doug Gwyn.
>Here's what I've tried to send:
>    Thank you very much for your postings in comp.lang.c.
>    I very much appreciate the work you put into them.
>

Richard included this in response to a flame I wrote criticising Doug on a
number of points.

To a certain extent I agree with the sentiments expressed above by Richard
even though (if anyone cares) I sometimes vent my frustration at some of
Doug's idiosyncratic responses.

If you hold yourself up as an authority, as Doug does, you must be very
careful to maintain your credibility.  Unfortunately, Doug often appears to
not know when to keep his mouth firmly shut and leave things well alone.  He
appears to always need to justify everything he says or is trivially
criticised for, even if this means getting into arguments which at best,
border on the specious or untenable.

Now, fair enough, this is Doug, and he can only act as his personality
dictates, but it *is* sometimes annoying, and it leaves him open to this
sort of complaint (which he should probably learn to "verbally" ignore).
More important however, in my mind it denegrates the "quality" of his
postings and his credibility as an authority.  *Perhaps* he does not fully
realize the *responsibility* of the position he has voluntarily undertaken.

What does it matter if *I* spout off, who am I, but Doug has positioned
himself such that his readers should be able to rely on the veracity of his
remarks.  He should thus be careful what he says and how he says it.

Earlier gurus of 4 or 5 years ago, who, apart from the fact that they did
not seem to have any axe to grind as Doug often appears to have, would
rarely resort to sarcasm and downright dismissal of others views!  [Mind
you, Chris Torek seems to be getting a littly crotchetty in his old age
these days! (:-)].

I could go on, I'll spare you though (whew!) except to say that I *do*
believe that we should remember that Doug's position on the ANSI committee
gives him a certain power, but *not* necessarily a superior opinion on the
contentious issues we all discuss (argue? shout about? go to sleep over?...).

If anyone wants to follow up this posting, please choose an appropriate news
group.  Don't ask me, I don't know what's appropriate, but we'd better leave
this group for crying about the message rather than shooting the messengers
(:-).

Ray Dunn.  ..{philabs, mnetor, musocs}!micomvax!ray

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Portable asm

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6325
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:35 AST
Received: by UWAVM (Mailer X1.25) id 4131; Fri, 11 Mar 88 20:34:45 PST
Date:         Wed, 9 Mar 88 17:42:12 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         David Collier-Brown <daveb@geac.uucp>
Subject:      Re: Portable asm
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <7501@sol.ARPA> quiroz@cs.rochester.edu (Cesar Quiroz) writes:
| Herman Rubin has consistently criticized in this group high-level
| language designers/implementors for not producing the portable
| assembler he wishes to use [several paragraphs deleted]
| My personal guess is that, were he to try, Rubin would come out with
| a language in the general class of C/Bliss/BCPL.  The exercise would
| be fruitful still: no more negative comments, once he realizes that
| language designers are not (totally) crazy, and that "progress in
| programming", if anything, means getting *away* from the vagaries of
| the hardware.

   Published last year (or maybe the one before) in Dr. Dobb's: a
subset-language of C which was in fact an assembler for a 68k
machine.

   And the idea is to get away from the vagaries without losing
the capabilities.  The latter is surprisingly hard, the turing
machine notwithstanding.

--dave (doesn't anyone read any more?) c-b

--
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: The D Programming Language

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6343
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:42 AST
Received: by UWAVM (Mailer X1.25) id 4152; Fri, 11 Mar 88 20:37:31 PST
Date:         Wed, 9 Mar 88 14:50:24 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         BEATTIE <twb@hoqax.uucp>
Subject:      Re: The D Programming Language
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>


I have been trying to ignore this D discussion but it seems to be going on
forever.

Why is this D discussion in the C group?

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Why NULL is 0

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6390
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:43 AST
Received: by UWAVM (Mailer X1.25) id 4221; Fri, 11 Mar 88 20:40:44 PST
Date:         Fri, 11 Mar 88 23:34:09 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was ris@umd5.umd.EDU
From:         "Louis A. Mamakos" <louie@trantor.umd.EDU>
Subject:      Re: Why NULL is 0
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <124@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes:
>However, if I were writing a C compiler, I would choose a size for all
>pointers equal to the size of the largest possible pointer.

Please don't do this.  On, for example, our Unisys 1100 machine, a "regular"
pointer is 8 bytes long (2 words, 72 bits).  A pointer to a function is
64 bytes long (8 words, 288 bits).  Yes, this is a word-addressable machine
with 4 9-bit bytes per word. The existing semantics work just fine if
you don't assume programmer brain-damage.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: How not to write a loop

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6452
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:44 AST
Received: by UWAVM (Mailer X1.25) id 4316; Fri, 11 Mar 88 20:43:52 PST
Date:         Thu, 10 Mar 88 13:36:07 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Gerald Edgar <gae@osupyr.uucp>
Subject:      Re: How not to write a loop
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Lengthy discussion about loops such as:

>>>     float x;
>>>     for (x = 0; x < 20; x += .5) printf("%f\n", x);

How about this:

     float x;
     for (x = 0; x < 19.75; x += .5) printf("%f\n", x);

--
  Gerald A. Edgar                               TS1871@OHSTVMA.bitnet
  Department of Mathematics                     gae@osupyr.UUCP
  The Ohio State University  ...{akgua,gatech,ihnp4,ulysses}!cbosgd!osupyr!gae
  Columbus, OH 43210                            70715,1324  CompuServe

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Why NULL is 0

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6461
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:45 AST
Received: by UWAVM (Mailer X1.25) id 4332; Fri, 11 Mar 88 20:43:57 PST
Date:         Fri, 11 Mar 88 23:28:50 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         David Keppel <pardo@june.cs.washington.EDU>
Subject:      Re: Why NULL is 0
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <124@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes:
>However, if I were writing a C compiler, I would choose a size for all
>pointers equal to the size of the largest possible pointer.  This would
>allow code that passed uncasted NULL to work correctly, provided NULL
>is a type as large as a pointer.  This is not because dpANS says it
>should be so, but because so much code would break if it were not.
>Perhaps ANSI should add the restriction that all pointer types must be
>the same size in an effort to "codify common existing practice."

My guess is that you would want to do this only if you didn't care
whether your compiler produced efficient code or made "reasonable"
time/space efficiency tradeoffs.

I know we've gone over this a lot, and perhaps the topic should be
redirected to comp.arch or some such, but (if nobody minds too much)
could somebody who understands please tell me what kind of efficiency
you lose (in runtime, codespace, and dataspace) in trying to make
everything the most general pointer type (on existing architectures)?

I'd sure like to know.

 ;-D on  (Well it looked like luminous phosphor when I wrote it)  Pardo

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Another \"D\" idea: RPN (and more)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6470
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:45 AST
Received: by UWAVM (Mailer X1.25) id 4349; Fri, 11 Mar 88 20:44:04 PST
Date:         Tue, 8 Mar 88 16:51:00 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         justin@inmet.uucp
Subject:      Re: Another \"D\" idea: RPN (and more)
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>


/* Written  4:29 pm  Mar  3, 1988 by gwyn@brl-smoke.UUCP in inmet:comp.lang.c */
In article <12088@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes:
>I think that the one thing that really detracts from C is the fact that it
>isn't RPN.  Reverse-polish-notation has a lot of benefits.  First of all,
>we'd get the support of all the HP calculator lovers, all the FORTH users,
>and compiler writers would find it easier to write compilers since RPN is
>easier to parse.

This idea isn't totally off-the-wall, but it would move the D language
away from being a revised C and toward something markedly different.
/* End of text from inmet:comp.lang.c */

God, it's finally happened. I had heard about this trend, but I couldn't
believe it. But it's really true. Nobody on the net (except in talk.bizarre)
is capable of recognizing sarcasm without a row of smileys at the end!

Come on, people, *think* about what you're reading. If we really have lost
the ability to tell what tone the article was written in, it means that
English on the net has degenerated a lot more than I thought.

                    -- Justin du Coeur

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6354
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:46 AST
Received: by UWAVM (Mailer X1.25) id 4167; Fri, 11 Mar 88 20:37:39 PST
Date:         Wed, 9 Mar 88 17:20:17 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Alan J Rosenthal <flaps@dgp.toronto.EDU>
Subject:      Re: Header problems
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>


Doug Gwyn <gwyn@brl.arpa> wrote about NULL, and said that the proper
definition of it is ``#define NULL 0''.

dag@chinet.UUCP (Daniel A. Glasser) wrote:
>Your use of NULL === 0 promotes unportable code ... [moralizing deleted]
>
>On machines were sizeof int != sizeof(void *), the above definition will
>not work on older style function calls (without prototypes) or in var-arg
>situations.  Requiring sizeof int == sizeof(void *) is not a viable
>solution...
>
>    #define    NULL    ((void *)0)
>On older compilers, replace 'void' with 'char'.  This allows the use of
>a short NULL representation when the compiler is smart enough to use it
>but forces passing of NULL in argument lists as a pointer sized object.

This doesn't require sizeof(int) == sizeof(void *).  The assumption is
that you always cast NULL before passing it.  Casting is still required
if NULL is defined as ((void *)0); you can't assume that all pointers
have the same size or representation.  Passing a pointer to void to a
routine that expects a pointer to struct gosh is as big a mistake as
passing an int to a routine that expects a pointer to struct gosh.

By the way, if you call f(0) where f expects a char *, the requirement
for it to work is not simply that sizeof(int) == sizeof(char *), but
also that (int)0 and (char *)0 have the same bit representation.

With respect to your phrase "a pointer sized object" - there is no such
thing in C.  There may happen to be such a thing in a particular
implementation of C due to hardware considerations.  (Obviously, it is
usually advantageous to represent all pointers in the same way (but not
always); therefore this is a common occurrence.)

ajr
--
If you had eternal life, would you be able to say all the integers?

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6493
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:48 AST
Received: by UWAVM (Mailer X1.25) id 4373; Fri, 11 Mar 88 20:47:33 PST
Date:         Wed, 9 Mar 88 23:59:49 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Pablo Halpern <pablo@polygen.uucp>
Subject:      Re: Header problems
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

From article <3351@chinet.UUCP>, by dag@chinet.UUCP (Daniel A. Glasser):
>            A better way to do it, in each place you want to define NULL,
> is:
>
>     #ifndef    NULL
>     #define    NULL    ((void *)0)
>     #endif
>
> On older compilers, replace 'void' with 'char'.  This allows the use of
> a short NULL representation when the compiler is smart enough to use it
> but forces passing of NULL in argument lists as a pointer sized object.

Do NOT replace 'void' with 'char' for old compilers unless you are prepared
to cast every use of NULL to the pointer type you are assigning (or comparing,
etc.).  Most compilers will complain of a pointer type missmatch since
(char *) doesn't match (int *) or (struct foo *) etc..  I agree that for
ANSI compilers, the above is correct, since (void *) DOES match (int *)
by definition.  For compilers that don't support (void *), you must have
a compiler-specific definition of NULL:

    #define NULL 0        /* If sizeof(int) == sizeof(char *) */

or

    #define NULL 0L        /* if sizeof(long) == sizeof(char *) */

This avoids pointer type missmatches because all compilers let you compare
any pointer agains integer zero.  Since the above #defines
are necessarily machine (and compiler) specific, I put these
types of declarations in a file called "machine.h" which contains machine
and compiler-dependent declarations and is different for each compiler I
use.  "machine.h" is #include'd in all of my source files.

Pablo Halpern        mit-eddie \
Polygen Corp.        princeton  \ polygen!pablo
200 Fifth Ave.        bu-cs       /
Waltham, MA  02254    stellar   /

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: nasty evil pointers

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6417
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:47 AST
Received: by UWAVM (Mailer X1.25) id 4265; Fri, 11 Mar 88 20:41:06 PST
Date:         Thu, 10 Mar 88 00:46:25 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Dave White <backstro@silver.bacs.indiana.EDU>
Subject:      Re: nasty evil pointers
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <13100003@bucc2> brian@bucc2.UUCP writes:
>
>It would be nice if we could check every pointer as
>it was used...
>
>
>If pointer
>pointed, say, into the operating system or the text space, the function
>would print a message and exit(). Otherwise it would return.
>
>Without source to the compiler it could
>be a major project. Does anybody know a way this could be done, perhaps with
>something like lex?
>
Lattice C 3.0 (and, I suppose, more recent versions) allow the size of
the stack and the size of the heap to be specified at runtime -- one
uses an argument of the form
   =ssize/heapsize
which the runtime startup routine digests before calling main().
Given such a beast, Lattice can provide isxxxx() functions that
determine whether a passed pointer points within an expected space.
However, the programmer must call them explicitly.

This makes it possible to determine when a wild pointer endangers the
machine.  It has the disadvantage that the proper heapsize might need to
be fudged, as well as the stacksize....  developing code for 8086's anf
friends is painful enough...

The sanest way to do what you want automatically is to build it into the
compiler itself.  Because compilers frequently call internal functions not made
available to the user, and because of the difficulty of cases like the
one you mention, it just isn't practical to write a pre-processor for
this -- you'd be halfway to rewriting the compiler!
>---
>  When the going gets weird, the weird turn pro.
No, they just bring out an Optimizing Turbo 5.0 version :-)
--
backstro@silver.bacs.indiana.edu

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: sizeof(char)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6374
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:49 AST
Received: by UWAVM (Mailer X1.25) id 4203; Fri, 11 Mar 88 20:38:02 PST
Date:         Wed, 9 Mar 88 17:52:54 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Ray Butterworth <rbutterworth@watmath.waterloo.EDU>
Subject:      Re: sizeof(char)
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <2809@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
> >In article <1988Feb25.202237.8688@utzoo.uucp> henry@utzoo.uucp (Henry
 Spencer) writes:
> >>Most machines cannot handle bits with anywhere near the efficiency
> >>with which they handle bytes; the appropriate base unit for efficient code
> >>*is* the byte.
>
> "Word-addressible cannot handle bytes with anywhere near the efficiency
> with which they handle words; the appropriate base unit for efficient code
> is the word."  Right?
>
> On a word-addressible machine, there is a perceived need to address objects
> smaller than one word; hence most C compilers give you access to individual
> bytes via "char".  (There may be some that define char as a machine word, but
> I'm not familiar with any.)  Similarly, on byte-addressible machines there is
> a (less) perceived need to address objects smaller than one byte.

The Honeywell Bull GCOS-8 C compiler packs chars into individual bytes
for arrays and structure, but individual external, static, or auto char
variables occupy a full word.  Accessing words (36 bits) on this machine
is easy.  Accesing individual bytes is not (typically a 3 word instruction
is needed to access individual bytes).

Certainly as far as this machine is concerned, there is no reason to
say that sizeof(char) should be 1, any more than it should be 9.

If C left the units of sizeof up to the implementor it would solve
a lot of problems (e.g. none of the multi-byte character mess that
is now in the proposed standard, and the problems of having to have
functions that know about the two different types of strings).

Other than allowing sloppily written code to continue to be written,
I can see no reason whatsoever for requiring that sizeof(char) be 1.
In Japan it could be 2, while on machines that do a lot of bit
manipulation it could be 16.  Both are appropriate for their needs.
Compiler writers that want to continue to support their old code
that assumed sizeof(char)==1 are free to write their compilers with
that same assumption.  But requiring sizeof(char)==1 on all compilers
imposes a needless limit on the language and forces implementors to
use various messy kluges and indefficiencies.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: How not to write a loop

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6425
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:49 AST
Received: by UWAVM (Mailer X1.25) id 4281; Fri, 11 Mar 88 20:41:13 PST
Date:         Wed, 9 Mar 88 03:11:24 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Hume Smith <850347s@aucs.uucp>
Subject:      Re: How not to write a loop
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

ok@quintus.UUCP (Richard A. O'Keefe) wrote in <712@cresswell.quintus.UUCP>:
>In article <832@unmvax.unm.edu>, mike@turing.UNM.EDU (Michael I. Bushnell)
 writes:
>> I see NOTHING which precludes:
>>     float x;
>>     for (x = 0; x < 20; x += .5) printf("%f\n", x);
>> The output would, of course, be
>>     0.0
>>     0.5
>>     ...
>>     19.5
>
>You should not be surprised to see as the last value
>    19.99999
>I just tried the very similar loop
>    for (x = 0; x < 21; x += .3)    /* .3 divides 21 exactly */
>By analogy with your "of course", the last output should obviously
>be 20.7.  In fact, when I tried it just now, the last output was
>    20.999994

I would be quite surprised to see 19.99999 come out in the former
loop.  .5 is exactly representable in floating binary, and should cause
no problem as an increment.  .3 is not representable in a finite binary
fraction (.01001 something, it repeats eventually), and cannot be summed
up to get an integral value.

If the machine did its arithmetic in decimal (Texas Intstruments?  Sharp?)
then the .3 increment would again not be a problem, since the representation
is exact again.

This, however, is the point.  The behaviour of a particular increment
is unreliable.

(Not to be insulting at all, but this may be why our Computer Science
department makes its majors take our Numerical Methods Course.  The
very first thing we do is Machine Epsilon and roundoff error.  This
comment is just to make enough text to keep inews happy.)
--
  Hume Smith                        UUCP:
Math Department     {uunet|watmath|utai|garfield|mnetor}!
   Acadia U                   dalcs!aucs!850347s

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Portable "asm" <-- portable? since when?

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6433
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:50 AST
Received: by UWAVM (Mailer X1.25) id 4297; Fri, 11 Mar 88 20:41:20 PST
Date:         Wed, 9 Mar 88 23:22:46 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         MH Cox <cox@bentley.uucp>
Subject:      Re: Portable "asm" <-- portable? since when?
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1355@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes:
>In article <697@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>|In article <7401@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>|> In article <2738@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>|> >Clearly, assembler statements should have been defined as:
>|> >#asm <statement>
>|> >instead of
>|> >asm("statement");
>|>
>|> A properly-designed system programming language should not have such
>|> a feature at all.  (It is not guaranteed in C, either.)
>
>What's all this about #asm < > ?
>
>First, #asm is really a way to change programming languages in
>mid-stream. Second, kindly explain how #asm sections are portable?
>Third, why not use separate assembly modules instead? If you _really_ need
>the flexibility of assembly to do low-level programming, use an
>assembler. I can see no need to mix assembly and C at the C source
>level (why was the language designed in the first place?).


If the #asm has to come back, let's just revert to the old K&R style:

    #asm
    ; assembly goes here
    #endasm

I agree with Dave whole-heartedly that we don't need yet another #asm
(or to re-adopt the old style).  It's against the "spirit" of the maxim,
"Isolate your machine-dependent code."

Now to change the subject and completely contradict myself...

I *would* like to see the "interrupt" keyword added to ANSI C (or D).
For a language to claim to be a system programming language and not
provide the capability to write interrupt routines is a major oversight
(although K&R seemed to do fine without it :-).  Both Borland and
Microsoft have added this capability, e.g.:

    interrupt int21()
        {
        }

The function int21's address can now be placed in an interrupt vector
to do interrupt processing.  Although this is non-portable, it sure
does make writing interrupt routines much easier.

Also, I would like to see named access to specific CPU registers included
in ANSI C, e.g. AX, BX, R0, R1, etc.  Borland does a nice job of this
by using _AX, _BX, etc as predefined variables for accessing CPU
registers (from what I've heard about the ANSI standard (I don't have
the latest copy), symbols beginning with underscore and in
all capital letters are reserved for use by the compiler.  So even with
this CPU register "extension", Borland's compiler is still a "conforming"
compiler!  Maybe other compiler vendor's will follow suit (are you
listenin' Microsoft ;-) and make CPU register access a common feature.

I think with the combination of the "interrupt" keyword and CPU register
access, that would eliminate 90% of the reasons for reverting to
assembly langauge.

>Do *not* mix languages in a single source file.

Dr. Codd would disagree (see March 88 issue of _Computer Language_).
What about SQL?  I find C combined with embedded SQL and good forms and
menu libraries to be one of the best application development
environments going!
--

==========================================================================
Michael H. Cox            ARPA:  moss!bentley!cox@rutgers.edu
AT&T Bell Labs            UUCP:  don't know (can anyone help?)
184 Liberty Corner Road
Rm 3B-Q15
Warren, NJ  07060
(201) 580-8622
==========================================================================

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: == vs =

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6366
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:52 AST
Received: by UWAVM (Mailer X1.25) id 4186; Fri, 11 Mar 88 20:37:54 PST
Date:         Thu, 10 Mar 88 09:24:19 est
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Dave Sill <dsill@NSWC-OAS.arpa>
Subject:      Re: == vs =
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <931@micomvax.UUCP> Ray Dunn <micomvax!ray> writes:
>I assume everyone still remembers this discussion, my systems news
>processing is so behind that......anyway....

I'm sure they wish they could forget it by now.

>In <11915@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) suggests that the
>answer is "using competant [sic] C programmers".
>
>This attitude, as well as being incompetently arrogant, just fails to
>recognize the realities of life.

Yeah, right, and it's realistic to expect something as fundamental as
the assignment operator to be changed at this point.  That remark
*was* flippant, for which I apologize.

>What he is [indirectly] saying, for example, is:
>
>...that lint is unnecessary, we should rely on the competence of the
>programmer and not use lint.

Not at all true.  I'm a firm believer in `lint'.  If you want to make
your `lint' complain about "=" in conditional contexts, that's fine
with me.  I don't think you should expect the language to be changed
just because you and a few others want it to.

>>...that we should rely on his own (in)ability to spell rather than attempt
>to define a spelling methodology that would avoid him making errors [I don't
>believe in spelling wars, but this was too relevant to avoid].

Yes, a perfect example!  I misspelled "competent", a common enough
mistake, but you don't hear me saying we should change the spelling of
"competent" to "competant", do you?  It's just more trouble than it's
worth, even if many people make the same mistake.  [As an aside, I
*do* have a spelling methodology.  I run `ispell' on all my postings.
I fixed the misspelled "competent", but overwrote the fixed version
when I went back into emacs to make other changes.]

>...that the recent language extensions which, for example, allow parameter
>type specifications, are unneccessary [sic] because we should rely on the
>programmer to always give the correct argument types to function calls!

I've said it before: I think function prototypes are A Good Thing.  I
just don't think they should have been added to C.  C + x != C, where
x = {function prototypes, honored parentheses, et cetera}.

>Dave, don't you believe in removing from system designs, as much of the
>human ability to make mistakes as possible?

Absolutely.  But I also realize that some things are just too hard to
change.  The way to fix them is to design a new system without them
(hint: what comes after C?).

>> Like it or lump it.  It will never change.
>
>Dave, the beauty of making statements like this and acting on them, is that
>you will always be right!  It is wonderfully self fulfilling.  You'll never
>achieve anything of course, but you'll always be right!

I'm not being stubborn or arrogant, I'm being pragmatic.

>Remember me the next time you discover a "stupid" error in the code you are
>writing, or when a typo costs you a couple of days work, or a poorly
>designed user interface costs you a bonus!  All of these could be avoided if
>you were competent in handling them!

How many times can *you* use "competent" in one message?

>Followups should perhaps be sent to alt.flame, you will notice the complete
>absence of smiley faces (or is that spelt faeces)?

I think that's "feces". :-)  I also think we should drop this
discussion from comp.lang.c, but use e-mail if we really must continue
it.

=========
The opinions expressed above are mine.

"I have enough trouble socializing with people.  I don't need some
object saying `good morning' to me."
                    -- Ted Nelson

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: nasty evil pointers

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6552
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:58 AST
Received: by UWAVM (Mailer X1.25) id 4393; Fri, 11 Mar 88 20:57:32 PST
Date:         Thu, 10 Mar 88 04:06:23 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Patrick Bennett <null@bsu-cs.uucp>
Subject:      Re: nasty evil pointers
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1159@silver.bacs.indiana.edu>, backstro@silver.bacs.indiana.edu
(Dave White) writes:
> In article <13100003@bucc2> brian@bucc2.UUCP writes:
> >
> >It would be nice if we could check every pointer as
> >it was used...
> >
> >
> >If pointer
> >pointed, say, into the operating system or the text space, the function
> >would print a message and exit(). Otherwise it would return.
> >

OS/2 provides this...  Different memory areas can have varying levels of
protection.  When this protection is broken, whether by attempting to modify,
read, whatever (depends on the protection) the program is promptly aborted but
with appropriate error info...

Although I personally don't have or use OS/2 I obtained this information from
the OS/2 Programmer's Guide by Ed Iacobucci (The leader of the IBM OS/2
Design Team)

Sounds great to me...

--
----
Patrick Bennett     UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!null

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Portable "asm" (Was: The D Programming Language)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6572
          for SXJVK@ALASKA; Fri, 11 Mar 88 20:08 AST
Received: by UWAVM (Mailer X1.25) id 4412; Fri, 11 Mar 88 21:08:08 PST
Date:         Mon, 7 Mar 88 22:42:20 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Tim Boemker <boemker@hpfcdc.HP.COM>
Subject:      Re: Portable "asm" (Was: The D Programming Language)
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Since the interface between C and in-line asm seems to be so
problematic (not to mention non-portable), why not write
those routines that should be written in assembly in assembly?

(Please don't tell me about needing just a rotate here or there
for performance; reconsider the original partitioning of the task
and find an alternative that separates the high-level part and
the low-level part.)

(Yes, I have written separately compiled assembly routines, and
I have repartitioned tasks to find an aesthetically appealing,
efficient alternative.)

Tim Boemker

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: I forget what it was originally called.

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6593
          for SXJVK@ALASKA; Fri, 11 Mar 88 20:28 AST
Received: by UWAVM (Mailer X1.25) id 4428; Fri, 11 Mar 88 21:15:23 PST
Date:         Mon, 7 Mar 88 16:21:36 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Mike McNelly <mike@hpfclq.HP.COM>
Subject:      Re: I forget what it was originally called.
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Not only do different types cause changes in the order of evaluation,
but different classes may also cause differences.  C compilers make
choices on the order of evaluation based on the "cost" of evaluating a
subexpression.  Pcc compilers typically evaluate a a subexpression with
a high cost in register resources first.

As a specific example, you may find your expression compiled differently
if "i" is declared to be a register variable than if it was an auto or a
static.

Frankly I have little sympathy with anyone writing code in this manner.
It's cute but it's also no more efficient than alternatives that do what
you really wanted to do in a much less ambiguous fashion.  If you
inherited this code you have my condolences.



Mike McNelly
hplabs!hpfcla!mike

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6644
          for SXJVK@ALASKA; Fri, 11 Mar 88 20:37 AST
Received: by UWAVM (Mailer X1.25) id 4463; Fri, 11 Mar 88 21:36:47 PST
Date:         Thu, 10 Mar 88 17:16:56 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was netnews@psuvax1.cs.psu.EDU
From:         Scott Schwartz <schwartz@gondor.cs.psu.EDU>
Subject:      Re: Pascal --> C question
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <4940001@hpiacla.HP.COM> mlight@hpiacla.HP.COM (Mike Light ) writes:
>>    SinWave: packed array[0..255] of char;
>>    char SinWave[256];

>Almost any pascal-ism has an equivalent in C (but not necessarily
>the other way around).

Except that the useful ones are never that easy.  One of my favorites:
    bitstring: packed array[0..1023] of boolean;
In C you have to do bit-fiddling by hand to get the same effect.

-- Scott Schwartz                       | Your array may be without head or
        schwartz@gondor.cs.psu.edu      | tail, yet it will be proof against
                                        | defeat.  -- Sun Tzu, "The Art of War"

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: nasty evil pointers

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6670
          for SXJVK@ALASKA; Fri, 11 Mar 88 20:59 AST
Received: by UWAVM (Mailer X1.25) id 4485; Fri, 11 Mar 88 21:48:29 PST
Date:         Thu, 10 Mar 88 16:46:16 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Jack Morrison <jackm@jpl-devvax.jpl.nasa.GOV>
Subject:      Re: nasty evil pointers
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <13100003@bucc2> brian@bucc2.UUCP writes:
>
>It would be nice if we could check every pointer as
>it was used...

Funny how often I see things in this newsgroup that can be answered
with two words:

    try Ada.

Even funnier because I still prefer using C.

--
Jack C. Morrison    Jet Propulsion Laboratory
(818)354-1431        jackm@jpl-devvax.jpl.nasa.gov
"The paycheck is part government property, but the opinions are all mine."

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Portable "asm" (Was: The D Programming Language)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6737
          for SXJVK@ALASKA; Fri, 11 Mar 88 21:08 AST
Received: by UWAVM (Mailer X1.25) id 4533; Fri, 11 Mar 88 22:07:32 PST
Date:         Thu, 10 Mar 88 18:08:20 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was netnews@PT.CS.CMU.EDU
From:         Eddie Wyatt <edw@IUS1.CS.CMU.EDU>
Subject:      Re: Portable "asm" (Was: The D Programming Language)
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> Since the interface between C and in-line asm seems to be so
> problematic (not to mention non-portable), why not write
> those routines that should be written in assembly in assembly?

To which the obvious reply is speed - functions invocation can be
RELATIVELY expensive.  The time taken to invoke a subroutine may
out way any gains that the asm statement made. Disclaimer - I don't use
asm - don't plan on it either.



--

Eddie Wyatt                 e-mail: edw@ius1.cs.cmu.edu

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  ANSI C & Fortran 8x - Expand cpp to partially support generalized

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6866
          for SXJVK@ALASKA; Fri, 11 Mar 88 22:24 AST
Received: by UWAVM (Mailer X1.25) id 4602; Fri, 11 Mar 88 23:23:50 PST
Date:         Thu, 10 Mar 88 18:26:49 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was news@sun.uucp
From:         David Hough <dgh%dgh@Sun.COM>
Subject:      ANSI C & Fortran 8x - Expand cpp to partially support generalized
              precision
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

I've previously proposed that Fortran 8x include the C preprocessor,
and that ANSI C support a limited interface to Fortran-77.
While thinking about Bob Corbett's comments about a related
Fortran 8x issue, generalized precision, a light flashed (fuse blowing?)
and the right thing to do seemed clear.  And unlike some of my
other comments, this one touches an issue dear to almost every
C programmer.  So here's what I'll propose to X3J11, modified
by the usual insightful reactions I expect you'll post:

Comment #26, Section 3.8.8 and  2.2.4.2: predefine  generalized precision macros

     The generalized precision proposal  in  Fortran  8x  is
complicated  and  controversial, yet responsive to a widely-
recognized need among  implementers  of  portable  numerical
software.   The  same need is most widely felt in the C com-
munity as a question like this: what is the  most  efficient
integral  type  that  contains  all integers in the range [-
99999,99999] ?

     Recommendation: To portably declare such types, add the
following predefined macros to 3.8.8:

     __int__(p) is evaluated to the name of  the  smal-
     lest  signed int type that contains all the signed
     p-digit  integers,   i.   e.   the   interval   [-
     (10**p)+1,10**p-1].

     __unsigned__(p) is evaluated to the  name  of  the
     smallest  unsigned  int type that contains all the
     p-digit unsigned  integers,  i.  e.  the  interval
     [0,10**p-1].

     __float__(p,r) is evaluated to  the  name  of  the
     smallest floating-point type that contains exactly
     all the p-digit signed integers,  i.  e.  all  the
     integers in the interval [-(10**p)+1,10**p-1], and
     contains 10**r and  10**-r  within  its  range  of
     positive model numbers.

     __INTEGER__(p) is evaluated to the Fortran name of
     the  type  corresponding  to    __int__(p,r),  or to
     INTEGER is no Fortran compiler is supported.

     __REAL__(p,r) is evaluated to the Fortran name  of
     the  type  corresponding  to   __float__(p,r), or to
     REAL if no Fortran compiler is supported.

     __COMPLEX__(p,r) is evaluated to the Fortran  name
     of   the   complex   type   whose  components  are
     __float__(p,r), or to COMPLEX if no  Fortran  com-
     piler is supported.

     All  the  precision-  and  range-dependent  macros
     fail, terminating compilation, if the precision or
     range requirements can't be met by  any  supported
     type.

     Recommendation:  In  order  that  the  C  pre-processor
itself  may  be  written  portably,  the  C run-time library
should provide certain corresponding string-valued functions
that  return the appropriate type for a particular implemen-
tation, or a null string on failure.  Add the  following  in
<float.h> to implement the corresponding cpp macros:

char * int__  (int p);
char * unsigned__  (int p);
char * float__  (int p; int r);
char * INTEGER__  (int p);
char * REAL__  (int p ; int r);
char * COMPLEX__  (int p ; int r);

David Hough

ARPA: dhough@sun.com
UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Wanted!!  Lattace - C Manual

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6883
          for SXJVK@ALASKA; Fri, 11 Mar 88 22:26 AST
Received: by UWAVM (Mailer X1.25) id 4629; Fri, 11 Mar 88 23:25:40 PST
Date:         Wed, 9 Mar 88 05:12:21 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         ark@alice.uucp
Subject:      Re: Wanted!!  Lattace - C Manual
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <12150@brl-adm.ARPA>, V064EHX5@ubvmsc.cc.buffalo.EDU writes:
> Any one know where I can get a Lattace - C manual free or very cheap?? Reply
 to V064ehx5.  Thank you!

In other words, you've stolen a copy of the compiler and now
you want someone to steal a copy of the documentation for you.

And you have the gall to admit it in public.

Amazing.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: sizeof(char)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6971
          for SXJVK@ALASKA; Fri, 11 Mar 88 23:01 AST
Received: by UWAVM (Mailer X1.25) id 4687; Sat, 12 Mar 88 00:00:55 PST
Date:         Thu, 10 Mar 88 22:08:16 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Doug Gwyn <gwyn@brl-smoke.arpa>
Subject:      Re: sizeof(char)
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <17395@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray
 Butterworth) writes:
>If C left the units of sizeof up to the implementor it would solve
>a lot of problems (e.g. none of the multi-byte character mess that
>is now in the proposed standard, and the problems of having to have
>functions that know about the two different types of strings).

>Other than allowing sloppily written code to continue to be written,
>I can see no reason whatsoever for requiring that sizeof(char) be 1.
>In Japan it could be 2, while on machines that do a lot of bit
>manipulation it could be 16.  Both are appropriate for their needs.

Yes!  I would appreciate it if you would send in a comment suggesting
that the approach in X3J11/86-205 (my sizeof(short char)==1 proposal)
should be considered in place of the proposed multi-byte character
support.  That is somewhat more ambitious than your sizeof(char)>=1
proposal, in that it provides an extra data type, so if that bothers
you you could suggest merely that the requirement sizeof(char)==1 be
dropped (which would leave the door open for later adoption of
something ling X3J11/86-205, but unfortunately would not eliminate
the proposed multi-byte character features).

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: I forget what it was originally called.

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6928
          for SXJVK@ALASKA; Fri, 11 Mar 88 22:50 AST
Received: by UWAVM (Mailer X1.25) id 4656; Fri, 11 Mar 88 23:50:17 PST
Date:         Thu, 10 Mar 88 19:30:54 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was netnews@PT.CS.CMU.EDU
From:         Eddie Wyatt <edw@IUS1.CS.CMU.EDU>
Subject:      Re: I forget what it was originally called.
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> Which brings me to another question:  How good are compilers these
> day?  Can they optimize just as well as a programmer (without
> resorting to assembly, that is) or not?  For example:
        [common subexpress example deleted]

  All depends on the compiler.  ccp is generally a bad optimizing compiler.
Green Hill gcc and Tartan C compilers are suppose to produce lightening fast
executables.  If I could only get gcc to compile a copy of "man", I
might use it.
--

Eddie Wyatt                 e-mail: edw@ius1.cs.cmu.edu

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Another \"D\" idea: RPN (and more)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7008
          for SXJVK@ALASKA; Fri, 11 Mar 88 23:18 AST
Received: by UWAVM (Mailer X1.25) id 4729; Sat, 12 Mar 88 00:18:22 PST
Date:         Thu, 10 Mar 88 22:13:35 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Doug Gwyn <gwyn@BRL-SMOKE.arpa>
Subject:      Re: Another \"D\" idea: RPN (and more)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <124200005@inmet> justin@inmet.UUCP writes:
>/* Written  4:29 pm  Mar  3, 1988 by gwyn@brl-smoke.UUCP in inmet:comp.lang.c
 */
>In article <12088@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes:
[...]
>God, it's finally happened. I had heard about this trend, but I couldn't
>believe it. But it's really true. Nobody on the net (except in talk.bizarre)
>is capable of recognizing sarcasm without a row of smileys at the end!

Actually, the two of us conspired in advance to post this dialogue.
But I did mean what I said in my response, unlike the originator
who was indeed just poking fun at the "D language" discussion.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Why I won't use ANSI C

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7033
          for SXJVK@ALASKA; Fri, 11 Mar 88 23:24 AST
Received: by UWAVM (Mailer X1.25) id 4744; Sat, 12 Mar 88 00:23:30 PST
Date:         Thu, 10 Mar 88 22:45:09 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Doug Gwyn <gwyn@brl-smoke.arpa>
Subject:      Re: Why I won't use ANSI C
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <933@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes:
>I could go on, I'll spare you though (whew!) except to say that I *do*
>believe that we should remember that Doug's position on the ANSI committee
>gives him a certain power, but *not* necessarily a superior opinion on the
>contentious issues we all discuss (argue? shout about? go to sleep over?...).

Thanks for your comments.

The one real advantage that participating in X3J11 has given me is that
I've heard all the arguments for changing = to := and the other such
ideas that keep popping up in this newsgroup many times before.  Some
topics, such as = vs. ==, have probably been sparked by magazine articles,
since the same old arguments keep getting repeated.

To give you some idea of what X3J11 is up against, of 717 public comments
from the first formal review, roughly 257 (that's 36%) were adopted in
some form.  The remaining 460 comments (64% of the total) had to be read,
understood, discussed, and explanations of why they were not adopted
had to be written.  The work kept the whole committee busy for many days.
It shouldn't be any wonder that some of us by this point have little
patience with the same suggestions that we've had to write rejection
rationale for over and over.

By the way, = vs. == was indeed considered by X3J11, but what can we do
about it?  If it were changed, the result could not reasonably be called
"C".  In fact, as I recall, most of us don't even think it should be
changed if it were feasible to do so.  The only approach that is at all
compatible with a large body of C code (but by no means all) would be
to introduce Boolean expressions and require that the control conditions
of if(), while(), for(), do..while() be Boolean expressions.  That would
solve the
    if ( a = 0 )
problem.  But it would break so much existing code that I for one am
sure that no such "C" standard [that requires a diagnostic when the
Boolean-expression constraint is violated] would be generally accepted.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Apology to Richard Harter

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7183
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:18 AST
Received: by UWAVM (Mailer X1.25) id 4835; Sat, 12 Mar 88 02:17:15 PST
Date:         Wed, 9 Mar 88 17:44:39 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Dave Burton <daveb@laidbak.uucp>
Subject:      Apology to Richard Harter
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <25387@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
|In article <1354@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes:
|>Please don't design D until you understand C.
|Er, Dave, may I suggest it is inadvisable to make remarks such as
|"Please don't design D until you understand C".

You're right. I'm sorry for the slight.
The remark was not intented to be a slurr on your personal abilities,
rather a plea against throwing features at a language.
--
--------------------"Well, it looked good when I wrote it"---------------------
 Verbal: Dave Burton                        Net: ...!ihnp4!laidbak!daveb
 V-MAIL: (312) 505-9100 x325            USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h>                          Naperville, IL  60540

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7209
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:20 AST
Received: by UWAVM (Mailer X1.25) id 4882; Sat, 12 Mar 88 02:18:05 PST
Date:         Thu, 10 Mar 88 18:04:34 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Chris Torek <chris@mimsy.uucp>
Subject:      Re: Header problems
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

[This makes three.]
In article <121@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes:
>For compilers that don't support (void *), you must have
>a compiler-specific definition of NULL:

No.

>    #define NULL 0        /* If sizeof(int) == sizeof(char *) */
> or
>    #define NULL 0L        /* if sizeof(long) == sizeof(char *) */

Either is technically legal.  The former suffices, is not machine
dependent, and is correct.

>Since the above #defines are necessarily machine (and compiler) specific,

The definition of NULL (as 0, or if you have a dpANS-conformant
compiler, as (void *)0) is not machine dependent.  What *is* machine
dependent is whether uncasted 0 in unprototyped function calls appears
to work.  Using uncasted 0L appears to work (but is nonetheless wrong)
on IBM PCs using large model compilers.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:    chris@mimsy.umd.edu    Path:    uunet!mimsy!chris

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Turbo Pascal -> MSC translator

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7199
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:19 AST
Received: by UWAVM (Mailer X1.25) id 4867; Sat, 12 Mar 88 02:17:30 PST
Date:         Thu, 10 Mar 88 13:26:23 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Matt Burdick <burdick@iuvax.cs.indiana.EDU>
Subject:      Turbo Pascal -> MSC translator
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>


A few months ago, there was a discussion on the net about a Turbo
Pascal to Microsoft C translator that Microsoft was giving away.
There was a toll-free number at Microsoft to order it from, but I have
since deleted that info.  If anyone still has the number, could you
e-mail it to me?  I will post it if/when I get it.

Has anyone used it and thought it useful?

                            -matt
--
UUCP: {ihnp4,pyramid,akgua}!iuvax!burdick    All these nodes are yours
ARPA: burdick@iuvax.cs.indiana.edu        Except nsavax
BITNET: burdick@iubacs.bitnet            Attempt no logins there
                        Use them together
                        Use them in peace

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7218
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:22 AST
Received: by UWAVM (Mailer X1.25) id 4899; Sat, 12 Mar 88 02:18:11 PST
Date:         Thu, 10 Mar 88 23:16:49 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was news@sigi.Colorado.EDU
From:         Frank Swarbrick <swarbric@tramp.Colorado.EDU>
Subject:      Re: Pascal --> C question
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <3352@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott Schwartz)
 writes:
:In article <4940001@hpiacla.HP.COM> mlight@hpiacla.HP.COM (Mike Light ) writes:
:>>    SinWave: packed array[0..255] of char;
:>>    char SinWave[256];
:
:>Almost any pascal-ism has an equivalent in C (but not necessarily
:>the other way around).
:
:Except that the useful ones are never that easy.  One of my favorites:
:    bitstring: packed array[0..1023] of boolean;
:In C you have to do bit-fiddling by hand to get the same effect.
:

How about:

typedef char bool;
bool bitstring[1024];

Or does the "packed" thing in Pascal have some special meaning?  I never could
figure out what the difference between a packed array and a regular array was.

Frank Swarbrick (and his cat)
swarbric@tramp.UUCP               swarbric@tramp.Colorado.EDU
..!{hao|nbires}!boulder!tramp!swarbric
"Can't help about the shape I'm in.
 I can't sing, I ain't pretty, and my legs are thin."

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: The D Programming Language: got

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7227
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:23 AST
Received: by UWAVM (Mailer X1.25) id 4915; Sat, 12 Mar 88 02:18:54 PST
Date:         Wed, 9 Mar 88 14:16:00 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         mcdonald@uxe.cso.uiuc.EDU
Subject:      Re: The D Programming Language: got
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>



>There are only three reasons for using a goto.  Firstly, to implement a
>control structure not directly available in the language in question.  This
>"deficiency" is not necessarily bad; I've used goto to emulate coroutines, but
>I probably wouldn't want to see coroutines added to the language.  If you
>remove goto but then add every other possible flow construct just to avoid the
>desire for a goto, you end up with BLISS.  Let's not do that.

>Secondly, error handling, which could be considered a special case of the
>first reason in that it emulates an exception construct of some type.  This
>includes not only cleanup-and-return but also retry-operation; sometimes a
>simple backward goto is clearer than a while.

>Thirdly, you can use a goto if you really, really want to, a whole lot.  :-)
>(I use this as my universal escape clause.)

I've only used goto's for non-error handling cases once in C. This is,
I guess, an example of Heuer's third case. The particular event was
the input parser for my text adventure "World". A logic diagram for this
is, like the English language it must decipher, a bowl of spaghetti.
I tried for quite a while it untangle it, and finally gave up. The
only way I was ever able to get rid of the goto's was to define a
"state variable" which would be set to some "magic" number at the
end of every block of code ending in a goto. Then I put everything
in a big case statement, going to the appropriate place depending on this
magic variable. The case statement was inside a do ... while(statevar != QUIT).
This gets rid of the goto's, but you are left with the magic numbers.
Do you leave them as numbers? No, this is not easy to read, so you give
them symbolic names that are #defined somewhere in the upper reaches of the
program. At this point I get thinking "Why not just leave in the goto's,
and give the labels the appropriate names?"
    It seems to me that if you reach the point where you have to use
the formally guaranteed-to-work method of removing goto's, you might as
well leave them in.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Pointers to functions

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7237
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:24 AST
Received: by UWAVM (Mailer X1.25) id 4931; Sat, 12 Mar 88 02:19:22 PST
Date:         Thu, 10 Mar 88 12:53:33 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "ELIN Forsch.z." <RCVIE@TUVIE>
Subject:      Re: Pointers to functions
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <7811@tut.cis.ohio-state.edu- mills-cl@pike.cis.ohio-state.edu
(christopher mills) writes:
-/*   I think D should have Ada-style comments...  */
-
-    Hello there.  I was writing a compiler for a simple C-like language of
-my own design for a single-board 6809 computer of mine, and I got around to
-the pointer arithmetic part and wondered what C does when you try to do
-pointer arithmetic on a pointer to a function.  I figgured it would generate
-an error (since functions do not have a "size"), but being curious, I tried it
-on a few C compilers I had around.  Suprisingly, many don't flag it as an
-error at all and do something implementation-defined and unpredictable (for
-example, Lattice C 3.10 on the Amiga treats it as if it were a char *, which
-I find odd, because it generates 68000 code which must be even-address
-aligned - I would have at least expected it to treat it as a short *).
-    K&R doesn't say anything about this (as far as I know).  I think it
-shows a breakdown in the typing system - pointers to functions aren't really
-pointers, but a distinct type.  Thoughts?  Flames?

Neither. A correction: K&R say (in my German edition) that only a pointer
to an arry element and an integer may be added or subtracted and that no
other (pointer) arithmetic is allowed. The dpANS says that "one operand shall
be a pointer to an object and the other shall have integral type". An object
is defined as "a region of data storage in the execution environment, the
contents of which can represent values". This is a more liberate definition
for pointer arithmetic than K&R have. In any case, pointer arithmetic on
pointers to functions is prohibited.

In article <7689@pur-ee.UUCP- hankd@pur-ee.UUCP (Hank Dietz) writes:
-This reminded me of a long-standing inconsistency in C in treating
-labels.  The old pdp11 C compiler used to think labels were actually
-constant-valued pointers to instructions, and you could in fact use
-them that way.  According to K&R, this treatment was just plain wrong -
-labels are a separate type - but I had a few systems programmers
-telling me that the idea is useful AND THAT THEY HAD USED IT.
-
-It seems to me that address arithmetic on pointers to functions ought
-to be scaled to maintain alignment, as suggested above, and that this
-might be part of a "clean" assembly/monitor interface.  However, as I've
-pointed out, one could easily extend this concept to make labels be
-treated as the type "pointer to in-line code."  I'm not sure I like
-this idea, but, as noted above, I know at least a few C programmers
-who'd be happy I mentioned it.  Actually, I guess I'm against the idea
-because it would really destroy compile-time flow analysis...  but I
-felt I should point out the issue anyway.

The idea to have the same pointer arithmetic on labels as on pointers to
functions seems to be a good one (in my opinion). It could help system
programmers to solve some problems via tricky programming (I know, I know, ...
tricky programming should not be propagated, but some problems can be solved
*only* by tricky programming). Secondly this would allow additional entry
points into functions. It seems to me as if K&R had something like that in
mind when they reserved the keyword entry. Has anybody information why this
feature has never been implemented?

        Dietmar Weickert,
            ALCATEL-ELIN Research Center, Vienna, Austria.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Why he won't use ANSI C

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7246
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:25 AST
Received: by UWAVM (Mailer X1.25) id 4947; Sat, 12 Mar 88 02:19:35 PST
Date:         Thu, 10 Mar 88 19:00:03 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Chris Torek <chris@mimsy.uucp>
Subject:      Re: Why he won't use ANSI C
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <933@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes:
>To a certain extent I agree with the sentiments expressed above
[a `thank you' to Doug Gwyn that I deleted]
>by Richard even though (if anyone cares) I sometimes vent my frustration
>at some of Doug's idiosyncratic responses.

Venting frustration in netnews is something many will do (yes, I too),
though it is usually counterproductive.  Since it happens, readers of
this group (and other groups) should watch for it and try not to let it
affect them.

>If you hold yourself up as an authority, as Doug does, you must be very
>careful to maintain your credibility.

Here I will argue philosophy (another counterproductive effort :-) ).
I say one cannot `hold oneself up as an authority'.  There are two
kinds of Authority.  One boils down to `power'; in the Usenet
dementiarchy [*], at least, and to a fair extent in the ARPA-land
info-c mailing list, this meaning does not apply.  The other is, in
essence, `knowledge'; the only true Authority in this sense is that
which is demonstrated.  Hence it is his readers who (sensibly) regard
Doug Gwyn as an Authority on the latest doings of the ANSI X3J11
committee.  Thus it is (at least in part) up to those readers to
separate Gwyn-opinion from committee-fact.

----
[*] `Rule by madness'.  (I made it up.)


>What does it matter if *I* spout off, who am I, but Doug has positioned
>himself such that his readers should be able to rely on the veracity of his
>remarks.  He should thus be careful what he says and how he says it.

Perhaps so; but it *does* matter if you, or indeed anyone, `spouts off'.
As you yourself put it:
>... in my mind it denegrates the "quality" of [one's]
>postings and [one's] credibility as an authority.

>Earlier gurus of 4 or 5 years ago ... would
>rarely resort to sarcasm and downright dismissal of others views!

(I think your memory has mellowed the situation somewhat.)

>[Mind you, Chris Torek seems to be getting a little crotchetty in his
>old age these days! (:-)].

I am not!  Why you young whippersnapper, I will have you know . . . .
:-)  (Besides, I am only 24, and even among full mortals that is rarely
considered old, to say nothing of Halfelven.)

Seriously, though, anyone can rant, and most of us do; while as
authors we should try to minimise this, as readers we should also
expect it, and do our best to ignore it.

>If anyone wants to follow up this posting, please choose an appropriate news
>group.

I could not think of any better place (except perhaps /dev/null, but
then that was why I put in the Summary header above.).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:    chris@mimsy.umd.edu    Path:    uunet!mimsy!chris

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  HLLs vs asm (was Re: portable "asm")

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7257
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:27 AST
Received: by UWAVM (Mailer X1.25) id 4963; Sat, 12 Mar 88 02:20:38 PST
Date:         Thu, 10 Mar 88 04:13:35 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Dave Burton <daveb@laidbak.uucp>
Subject:      HLLs vs asm (was Re: portable "asm")
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

I'm redirecting this to comp.lang.misc - it's lost all its flavor of C.
(Herman, I won't be reading comp.lang.misc, if you want, Email me - Dave)

In article <703@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
|Frankly, I believe that if someone developed a decent high-level, overloaded
|operator, reasonable syntax assembler it would have a good chance of
|supplanting C.  Add the other useful features of C and you have a good
|language.

My definition of assembler may be antiquated, but it says that there is
a one-to-one (or one to _very_ few) source statements to target statements.
I do not think such a beast as your hypothetical super-assembler is likely.
I do think C could be improved on in several areas, but which direction?
Should C's successor be system implementation oriented, or general purpose
oriented; i.e: more explicit control of the underlying machine, or more
generalized, higher level constructions? #asm is not of the latter.

|Suppose that you have a situation in a program where the implementation of
|your compiler has done something bad, like use 10 instructions and 6 memory
|references where 2 instructions and no memory references can do the job.
|The overhead of a subroutine call is likely to be more than what can be
|saved; a goto construction may not work if part of the problem is that the
|compiler will mess up register use (very common).

The number of situations where the matter of a few microseconds is a
make or break proposition is extremely limited. Where they do occur,
they are non-portable. These situations are very likely best handled
in assembly for that routine, anyway.

|Also some of the very simple hardware operations which are useful for some
|problems have not been anticipated by the language developlers.  This is so
|often the case for simple operations frequently found in hardware.  More
|machines have a hardware operation &~, which most mathematicians normally
|use \ for, than have the operation &.  I am more likely to want to use &~.

If I understand you properly, you want to switch between a HLL and assembly,
with regularity, to use machine specific instructions. I think this is in
contrast to the basic principles of high-level languages. HLLs are designed
to allow a higher level of abstraction than assembly, and somewhat more
portability.

|If a programmer says that something is inline, and this should be a feature
|of any language, the compiler should at most point out why this is not good,
|but the judgment must be that of the programmer.

Something troubles me about this statement, but I don't know what. I'm
inclined to agree.

|> [ on language gurus claiming omniscience, deleted ]
|The language gurus may not claim this, but I am not so sure.  The
|designers of 4.xBSD clearly state in their assembler documentation
|that the assembler is _not_ for programmers, but for compiler designers
|and system maintainers.

I believe this is not so much omniscience as practicality. I *like*
programming in assembly. I like the control, the flexibility. But I
have never written a major application under Unix in pure assembly.
Why should I? I can be much more productive in C. Because it's so
inconvenient to do assembly hacking, almost nobody does it. With so
many using C, lisp, f77, ratfor, efl, what-have-you, why expend a great
deal of effort on an assembler used 99% percent of the time by automated
software?

|But in too many cases, the existing HLLs may produce good code if small
|modifications are made.  In many cases, these modifications are machine
|independent--I can give you cases of this.  It may even be as simple as
|saying
|    This is what is needed; implement this block efficiently, while
|    maintaining its compatibility with the rest of the program.
|
|That is another reason for asm.

Isn't this actually arguing against asm?

|> You presume that this same individual also knows how the HLL
|> implements itself on that machine. This is not the case. Very few people
|> that know both the HLL and the machine instruction set will know what kind
|> of code the compiler will produce.
|Why not?

OK, I know this is not quite the same, but consider interpretive languages.
Who knows what shadows lurk ... :-)
These include not only BASIC (ack!), lisp, prolog, sno[bol], but "4GL"s
like SQL, Informix, Accel and the too many others.
Even with compilers, many people do not _take the time_ to learn the
transformations performed upon their HLL by the compiler. I never bothered
to study the output of FORTRAN or Ada, but I know the assembly language
for the machines I write them on. The point is, I and most others don't
get paid to cogitate the most efficient possible expression for situation X.
(Not that I would mind! :-) It just isn't necessary to know.
--
--------------------"Well, it looked good when I wrote it"---------------------
 Verbal: Dave Burton                        Net: ...!ihnp4!laidbak!daveb
 V-MAIL: (312) 505-9100 x325            USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h>                          Naperville, IL  60540

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7371
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:41 AST
Received: by UWAVM (Mailer X1.25) id 5011; Sat, 12 Mar 88 02:41:06 PST
Date:         Fri, 11 Mar 88 01:41:57 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was netnews@psuvax1.cs.psu.EDU
From:         Scott Schwartz <schwartz@gondor.cs.psu.EDU>
Subject:      Re: Pascal --> C question
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes:
>:
>:Except that the useful ones are never that easy.  One of my favorites:
>:    bitstring: packed array[0..1023] of boolean;
>:In C you have to do bit-fiddling by hand to get the same effect.
>:
>typedef char bool;
>bool bitstring[1024];
>
>Or does the "packed" thing in Pascal have some special meaning?  I never could
>figure out what the difference between a packed array and a regular array was.

The "packed" thing has a special meaning.  I can't quote you from the
ANSI or ISO standards offhand, but the idea is that the compiler is
supposed to arrange that the packed structure takes up a minimal amount
of space (probably subject to some alignment restrictions).  So in the
example I gave each boolean would take up one bit, and there would be
1024 of them, the whole array taking up 128 bytes.  Unpacked, each
boolean would take up one, two, or maybe four (depending on how unlucky
you are) bytes.

In (I can't believe I'm about to type this, but...) the hypothetical
"D" language it would be nice to be able to say

    typedef bool bit;
    bool bitstring[1024];

but, alas....



-- Scott Schwartz                       | Your array may be without head or
        schwartz@gondor.cs.psu.edu      | tail, yet it will be proof against
                                        | defeat.  -- Sun Tzu, "The Art of War"

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Don't use Scanf()

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7390
          for SXJVK@ALASKA; Sat, 12 Mar 88 01:57 AST
Received: by UWAVM (Mailer X1.25) id 5026; Sat, 12 Mar 88 02:56:39 PST
Date:         Fri, 11 Mar 88 02:36:59 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Roland McGrath <rk9005@cca.ucsf.EDU>
Subject:      Re: Don't use Scanf()
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

One real stupidity I've seen many, many times is the
over-use of printf.  The printf functions have their uses,
and they do their job quite well, but please know what these
uses are!!

For example:
    printf("Hello world!\n");
Haven't you ever heard of puts????
    puts("Hello world!");    /* note the newline is appended    */
or
    printf("hi");
try fputs:
    fputs("hi", stdout);    /* no newline appended    */
What's that?  Oh, now you have to include <stdio.h> so
you can get the proper declarations of all these functions anyway?
Poor baby!

And the ultimate stupidity:
    printf("\n");
Get a brain!!!!!  You're using the function that can do complex
data formatted output to write one bleeping character!!!!!
Try
    putchar('\n');
If you include <stdio.h>, this will probably end up being a macro
that will write it out very fast.

I have even seen:
    sprintf(buf, "constant string");
Hey, Mr. Power-Programmer, ever heard of strcpy????


In general, if there's no format spec, don't use printf!!!!!!
--
    Roland McGrath
ARPA: roland@rtsg.lbl.gov roland@lbl-rtsg.arpa
UUCP: ...!ucbvax!lbl-rtsg.arpa!roland

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: sizeof(char)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7424
          for SXJVK@ALASKA; Sat, 12 Mar 88 02:18 AST
Received: by UWAVM (Mailer X1.25) id 5052; Sat, 12 Mar 88 03:18:15 PST
Date:         Fri, 11 Mar 88 18:26:54 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Rahul Dhesi <dhesi@bsu-cs.uucp>
Subject:      Re: sizeof(char)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <2328@bsu-cs.UUCP> I wrote:
>And nowhere do I find
>K&R saying that byte == char == 1 unit is simply a compiler peculiarity
>and not a design assumption in the language.

Looking again, more carefully this time, I find this on page 188:

     A byte is undefined by the language except in terms of the value
     of sizeof.

And yet, looking at the extensive discussion of a function alloc() to
allocate memory and a portable implementation of it, we find that char
and byte are used synonymously in the examples given.  See pages 96-98
and then 173-177.
--
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Bit Addressable Architectures

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7433
          for SXJVK@ALASKA; Sat, 12 Mar 88 02:19 AST
Received: by UWAVM (Mailer X1.25) id 5069; Sat, 12 Mar 88 03:18:26 PST
Date:         Wed, 9 Mar 88 14:47:24 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Frank Adams <franka@mmintl.uucp>
Subject:      Re: Bit Addressable Architectures
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1988Mar6.002518.945@utzoo.uucp> henry@utzoo.uucp (Henry Spencer)
 writes:
>As an extreme case,
>one can envision a bit-addressable machine -- that is, one whose pointers
>use the low-order three bits to indicate a bit within a byte -- that traps
>whenever those bits aren't zero, leaving the actual use of bit pointers
>entirely up to the software.  When all accesses were in fact aligned, this
>would incur essentially no overhead except the reduction in address space.

This may sound like an off the wall idea, but it makes a lot of sense to me.
This would mean that arithmetic on bit pointers can be done using the
standard arithmetic operations; and no special format is required for them.
Note that the software need not wait for a trap to deal with unaligned data
-- if it knows it is dealing with a bit pointer, it can extract and deal
with the low order bits itself.

As for the address space issue: I personally believe that 32 bit addresses
are too short, and that this will become apparent fairly quickly.  With a 64
bit address, one can afford to use 3 bits this way.
--

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Don't use Scanf()

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7456
          for SXJVK@ALASKA; Sat, 12 Mar 88 02:39 AST
Received: by UWAVM (Mailer X1.25) id 5085; Sat, 12 Mar 88 03:39:04 PST
Date:         Fri, 11 Mar 88 23:06:14 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         mike knudsen <knudsen@ihwpt.ATT.COM>
Subject:      Re: Don't use Scanf()
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Good points.  But if you already are using printf() in your
program (with a legitimate need for the formatting) in several
places, then substituting puts() where possible will make
your program object file bigger, not smaller, since
now the puts() code has to be linked in too.
Puts() and putchar() will be a little faster, but when you're
talking to humans who cares?

BTW, I once wrote a large interactive monitor for a free-standing
8086 board, using a C that had no I/O at all.  I wrote routines
to output %2x, %4x, and %5d as well as strings.
Took a lot of calls to do one good printf(),
but it IS possible and such custom I/O may save you bytes.
--
Mike J Knudsen    ...ihnp4!ihwpt!knudsen  Bell Labs(AT&T)
    Delphi: RAGTIMER    CIS: <memory failure, too many digits>
    "Just say NO to MS-DOS!"    "OS/2 == 1/2 of an OS"

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: Apology to Richard Harter

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7562
          for SXJVK@ALASKA; Sat, 12 Mar 88 03:27 AST
Received: by UWAVM (Mailer X1.25) id 5154; Sat, 12 Mar 88 04:26:55 PST
Date:         Fri, 11 Mar 88 05:28:14 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Richard Harter <g-rh@cca.CCA.COM>
Subject:      Re: Apology to Richard Harter
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1361@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes:
>
>You're right. I'm sorry for the slight.
>The remark was not intented to be a slurr on your personal abilities,
>rather a plea against throwing features at a language.

Ooooh.
You realize, don't you, that it is against net protocol to apologize.
You almost gave a heart attack from the shock! :-)  No offense taken,
and there is justice in your position.

Just be careful about these gratuitous apologies in the future or else
you will see the net.police descending upon you.
--

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
    Richard Harter, SMDS  Inc.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Recursion (was: The D Programming Language)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7576
          for SXJVK@ALASKA; Sat, 12 Mar 88 03:30 AST
Received: by UWAVM (Mailer X1.25) id 5170; Sat, 12 Mar 88 04:28:41 PST
Date:         Fri, 11 Mar 88 23:43:17 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         00704a-Liber <nevin1@ihlpf.ATT.COM>
Subject:      Recursion (was: The D Programming Language)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <704@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

There are two problems with this.  While using stacks may be easy to program,
it involves lots of loads and stores.  I know of at least one machine on which
the normal subroutine call and return do not use stacks.  Furthermore, if the
called routine may make additional calls, it may be necessary to use a
separate return stack, and this may require each such subroutine to maintain
its own return stack.  In some cases this should be the way to do things,
but not always.

I would not be so worried about the efficiency of passing values to and
from functions on non stack-based machines and be more worried about how
you are going to implement efficiently a language which allows recursion
(C, Pascal, etc.) on a non stack-based machine.  I do know that machines
like this exist (yea, I have programmed on a PDP-8), but I haven't seen an
efficient implementation of Pascal or C on any of these machines.  The only
model that I know of that supports recursion is a stack.  BTW, what I mean
by recursion is that if you graph out the functions in the order that they
are called and you find a cycle in it, it's recursive.

Another problem comes with inline functions.  I believe that many function
calls, if not most, should be inline.  In this case, I think the result should
go to its destination at the time produced.  If the destinations involve
registers or register indirects, the expression of the algorithm must take
the busy set of registers into account.  This admittedly makes coding
difficult, and is one reason why I believe DNA can optimize better than
silicon.  (The two should be used together, but I do not know of any compiler
which allows the programmer to even give it a hint as to how to optimize,
let alone improve the resulting product.)

As I have told you before, NOT ALL FUNCTIONS ARE INLINEABLE!!  Any function
that can be called recursively (see my above definition of recursive) an
unknown (at compile/link time) number of times cannot be inlined!!

Also, another reason that you may not want to inline functions is that on a
smaller machine (such as a PC), you may have to move to a larger memory
module because your activation record is much bigger (it might no longer
fit into a segment, etc.).

Thirdly, if you are calling shareable routines you cannot inline them,
since their code is never actually put into the text segment.

BTW, I am not against inlining per se (I like it much more than macros),
but I do not feel that it should be done if it might break the code (any
function that might be recursive shouldn't be inlined).  'inline' should
be a hint in much the same way that 'register' is a hint (and NOT the way
'noalias' is a hint in the C draft standard).


Here is another proposition for the 'D' language:  the keyword 'unroll'
(see Jon Bentley's "Programming Pearls" for reference) should be allowed
in front of any *simple* for loop.  What this would do is, for example,
is change:

unroll for (i=1; i <= 4; i++)
    printf("String number %d is: %s\n", i, string[i]);

to:

printf("String number 1 is %s\n", string[1]);
printf("String number 2 is %s\n", string[2]);
printf("String number 3 is %s\n", string[3]);
printf("String number 4 is %s\n", string[4]);
i=5;

since the latter is more efficient with respect to speed.  Of course, the
comments I made above about potentially breaking code apply here is well
('unrolling' would only be a hint).  Comments??
--
 _ __            NEVIN J. LIBER    ..!ihnp4!ihlpf!nevin1    (312) 510-6194
' )  )                "The secret compartment of my ring I fill
 /  / _ , __o  ____         with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: nasty evil pointers

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7634
          for SXJVK@ALASKA; Sat, 12 Mar 88 04:04 AST
Received: by UWAVM (Mailer X1.25) id 5209; Sat, 12 Mar 88 05:03:32 PST
Date:         Fri, 11 Mar 88 23:54:38 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         00704a-Liber <nevin1@ihlpf.ATT.COM>
Subject:      Re: nasty evil pointers
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <13100003@bucc2> brian@bucc2.UUCP writes:
>It would be nice if we could check every pointer as it was used...

This seems to be more of a job for the OS than for the language.  If you try to
check every single use of pointers, you end up with a language like Pascal
:-).  I don't mind the checking of pointers as long as it doesn't interfere
with the efficiency that those of us who program in C have come to love :-).
Also, if the pointer checks find an error, I would like it to transfer control
to an error-handling section of my program so that I could either try to
recover or go down *gracefully* (saving calculated data, etc.).
--
 _ __            NEVIN J. LIBER    ..!ihnp4!ihlpf!nevin1    (312) 510-6194
' )  )                "The secret compartment of my ring I fill
 /  / _ , __o  ____         with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)

Subject:  Re: The D Programming Language

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7644
          for SXJVK@ALASKA; Sat, 12 Mar 88 04:05 AST
Received: by UWAVM (Mailer X1.25) id 5225; Sat, 12 Mar 88 05:04:25 PST
Date:         Thu, 10 Mar 88 21:26:58 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Stuart D. Gathman" <stuart@bms-at.uucp>
Subject:      Re: The D Programming Language
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <700@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> but even for direct operators.  For example, the infamous frexp function
> in C should not have the syntax

>     y = frexp(x,&n);

> but

>     y,n = frexp(x);

> This would, for example, allow n to be in a register, which is probably
> where it should be anyhow.

> Another example would be to have

>     q,r = a///b;

> where the quotient and remainder are simultaneously produced.  Possibly

Another example is string comparison.  I use a string compare function
that returns the index of the first different character.  I also
need the gt/lt/eq result.  Fortunately, in this case it is easily
computed by recomparing the chars at the index.  This is another case
of a double valued hardware primitive.  (Available on all three
of the architectures we use: Series/1, 80286, 68020.)
--
Stuart D. Gathman    <stuart@bms-at.uucp>
            <..!{vrdxhq|daitc}!bms-at!stuart>

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Why NULL is 0

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8001
          for SXJVK@ALASKA; Sat, 12 Mar 88 10:50 AST
Received: by UWAVM (Mailer X1.25) id 5338; Sat, 12 Mar 88 11:49:55 PST
Date:         Fri, 11 Mar 88 21:56:46 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Doug Gwyn <gwyn@brl-smoke.arpa>
Subject:      Re: Why NULL is 0
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <124@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes:
>Perhaps ANSI should add the restriction that all pointer types must be
>the same size in an effort to "codify common existing practice."

But it isn't existing practice.

If you mean, non-portable, buggy code is existing practice, well yes,
but so what?  That certainly shouldn't serve as the basis for a standard.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  SUN Env. Vars.

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8019
          for SXJVK@ALASKA; Sat, 12 Mar 88 10:51 AST
Received: by UWAVM (Mailer X1.25) id 5370; Sat, 12 Mar 88 11:50:10 PST
Date:         Fri, 11 Mar 88 17:35:10 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Stuart A. Werbner" <stu@linus.uucp>
Subject:      SUN Env. Vars.
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>


    Hello fellow SUN/UNIX enthusiasts.

    Could someone please mail me a list of all environment variables
    recognized by the Sun 3.x Operating System (and resident commands
    and utilities).  If not, could someone please tell me how to
    (easily) find such a list.

    Thank you.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8047
          for SXJVK@ALASKA; Sat, 12 Mar 88 10:51 AST
Received: by UWAVM (Mailer X1.25) id 5422; Sat, 12 Mar 88 11:50:37 PST
Date:         Thu, 10 Mar 88 19:02:12 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Mark Brader <msb@sq.uucp>
Subject:      Re: Header problems
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> By the way, if you call f(0) where f expects a char *, the requirement
> for it to work is not simply that sizeof(int) == sizeof(char *), but
> also that (int)0 and (char *)0 have the same bit representation.

*And* that the implementation passes integer and pointer type values to
functions in the same manner.  Remember, arguments can be passed in registers
and machines can have several types of registers.

*Never* say f(0) or f(NULL).

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
#define    MSB(type)    (~(((unsigned type)-1)>>1))

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8056
          for SXJVK@ALASKA; Sat, 12 Mar 88 10:52 AST
Received: by UWAVM (Mailer X1.25) id 5439; Sat, 12 Mar 88 11:50:45 PST
Date:         Fri, 11 Mar 88 23:57:37 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         00704a-Liber <nevin1@ihlpf.ATT.COM>
Subject:      Re: Pascal --> C question
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <3352@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott Schwartz)
 writes:
>Except that the useful ones are never that easy.  One of my favorites:
>    bitstring: packed array[0..1023] of boolean;
>In C you have to do bit-fiddling by hand to get the same effect.

Yes, but in C you are guaranteed that bits are actually used.  Not many
implementations of Pascal bother to implement packed arrays any differently
than non-packed arrays, so what you get is an array of 1024 words (where the
sizeof(word) is implementation-dependent).
--
 _ __            NEVIN J. LIBER    ..!ihnp4!ihlpf!nevin1    (312) 510-6194
' )  )                "The secret compartment of my ring I fill
 /  / _ , __o  ____         with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8077
          for SXJVK@ALASKA; Sat, 12 Mar 88 10:53 AST
Received: by UWAVM (Mailer X1.25) id 5474; Sat, 12 Mar 88 11:51:00 PST
Date:         Thu, 10 Mar 88 18:34:58 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was news@rtech.uucp
From:         Jim Shankland <jas@llama.rtech.uucp>
Subject:      Re: Header problems
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <3351@chinet.UUCP> dag@chinet.UUCP (Daniel A. Glasser) writes:
>Your use of NULL === 0 promotes unportable code, and is considered to be
>bad programming style in a world where portability across multiple machine
>architectures ... is required....  On machines were sizeof int !=
>sizeof(void *), the above definition will
>not work....  A better way to do it, in each place you want to define NULL,
>is:
>
>    #ifndef    NULL
>    #define    NULL    ((void *)0)
>    #endif

Ack!  Here it comes again!  Warm up the ``kill'' file.
Jim Shankland
  ..!ihnp4!cpsc6a!\
               sun!rtech!jas
 ..!ucbvax!mtxinu!/

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Another \"D\" idea: RPN (and more)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8271
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:24 AST
Received: by UWAVM (Mailer X1.25) id 5559; Sat, 12 Mar 88 12:24:25 PST
Date:         Sun, 6 Mar 88 17:14:47 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Gregory Conway <gregory@ritcsh.uucp>
Subject:      Re: Another \"D\" idea: RPN (and more)
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <12088@brl-adm.ARPA>, TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes:
>
> Another thing that "D" should have... actually not have, is pointers. At
> least 85% of the problems discussed here on Info-C are people who have
> some problem with confusion about pointers.  Removing pointers would solve
> this whole set of problems.
>

     You seem to me to be a little hasty here.  The problem has NOTHING to do
with pointers, but rather people who do not understand pointers who use them
anyways.  Pointers are the most powerful aspect of the C programming language
and are what make it such a joy to work with.  To para-phrase, pointers
don't kill, programmers do.


--
================================================================================
Gregory Conway@Computer Science House    UUCP: ...rochester!ritcv!ritcsh!gregory
Rochester Institute of Technology, Rochester, NY
    "I got an allergy to Perrier, daylight, and responsibility", Marillion

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: CPP defines...

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8297
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:29 AST
Received: by UWAVM (Mailer X1.25) id 5578; Sat, 12 Mar 88 12:29:11 PST
Date:         Thu, 10 Mar 88 23:38:46 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Nick Crossley <nick@ccicpg.uucp>
Subject:      Re: CPP defines...
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <179@istop.ist.CO.UK> rb@ist.CO.UK (News reading a/c for rb) writes:
>Here's a nasty little script that comes in useful when you
>want to know what your cpp *really* predefines: we have found
>that the man page is sometimes economical with the truth.
> ...
>strings -a -2 /lib/cpp | sed '/^a-zA-Z0-9_/!s/.*/#ifdef &\
>"%&"\
>#endif/p' |/lib/cpp |sed -n '/%/s/[%"]//gp'

Ah, but not all systems have their predefined symbols defined by cpp!  I know
of some which define some symbols in cc!  Thus, a better? more complete?
approach might be :-

strings <options as required> /lib/cpp /bin/cc |
sort -u |
sed -n '/^[a-zA-Z0-9_]*$/s//#ifdef &\
"%&"\
#endif/p' >cpp_test.c

cc -E cpp_test.c |
sed -n '/%/s/[%"]//gp'
--

<<< standard disclaimers >>>
Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA
Tel. (714) 458-7282,  uucp: ...!uunet!ccicpg!nick

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8306
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:30 AST
Received: by UWAVM (Mailer X1.25) id 5593; Sat, 12 Mar 88 12:29:18 PST
Date:         Fri, 11 Mar 88 18:40:35 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was netnews@psuvax1.psu.EDU
From:         Scott Schwartz <schwartz@gondor.cs.psu.EDU>
Subject:      Re: Pascal --> C question
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <760@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe)
 writes:
>In article <3353@psuvax1.psu.edu>, schwartz@gondor.cs.psu.edu (Scott Schwartz)
 writes:
>> So in the
>> example I gave each boolean would take up one bit, and there would be
>> 1024 of them, the whole array taking up 128 bytes.

>The trouble is that a Pascal compiler is absolutely free to ignore
>'packed' entirely.  When you say
>    var a: array [0.1023] of boolean;
>you have no guarantee at all that the compiler won't use 1024 "words".

Right.  Lots of (bad) compilers ignore "packed", just like some C
compilers ignore "register".   For the purpose of argument I was
assuming a decent pascal compiler.  The University of Sheffield, for
example, sells a pascal compiler for Prime 50 series machines that
implements "packed" down to the bit level.  There's nothing like
automatically taking advantage of your instruction set.

Anyway, enough pascal talk.  On to the next comp.lang.c topic!

-- Scott Schwartz                       | Your array may be without head or
        schwartz@gondor.cs.psu.edu      | tail, yet it will be proof against
                                        | defeat.  -- Sun Tzu, "The Art of War"

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Why NULL is 0

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8323
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:30 AST
Received: by UWAVM (Mailer X1.25) id 5618; Sat, 12 Mar 88 12:29:37 PST
Date:         Fri, 11 Mar 88 02:57:33 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Pablo Halpern <pablo@polygen.uucp>
Subject:      Re: Why NULL is 0
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

From article <10576@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):
> (You may wish to save this, keeping it handy to show to anyone who
> claims `#define NULL 0 is wrong, it should be #define NULL <xyzzy>'.
> I intend to do so, at any rate.)
>
> Let us begin by postulating the existence of a machine and a compiler
> for that machine.  This machine, which I will call a `Prime', or
> sometimes `PR1ME', for obscure reasons such as the fact that it
> exists, has two kinds of pointers.  `Character pointers', or objects
> of type (char *), are 48 bits wide.  All other pointers, such as
> (int *) and (double *), are 32 bits wide.

I must admit, you have come up with a situation where the uncasted
value NULL would be an incorrect parameter to a function that didn't
have a prototype regardless of the definition of NULL. (If you missed
the original posting, please don't flame about this.  Ask someone to
mail the original to you.)  In the situation mentioned, the compiler
could not know how wide to make the null pointer when passing it to the
function.  Indeed, even with NULL defined as (void *) 0, dpANS does not
say that the size of a (void *) is the same as the size of any other
pointer.

However, if I were writing a C compiler, I would choose a size for all
pointers equal to the size of the largest possible pointer.  This would
allow code that passed uncasted NULL to work correctly, provided NULL
is a type as large as a pointer.  This is not because dpANS says it
should be so, but because so much code would break if it were not.
Perhaps ANSI should add the restriction that all pointer types must be
the same size in an effort to "codify common existing practice."

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8352
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:33 AST
Received: by UWAVM (Mailer X1.25) id 5644; Sat, 12 Mar 88 12:33:27 PST
Date:         Fri, 11 Mar 88 11:32:41 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Richard A. O'Keefe" <ok@quintus.uucp>
Subject:      Re: Pascal --> C question
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <3353@psuvax1.psu.edu>, schwartz@gondor.cs.psu.edu (Scott Schwartz)
 writes:
> The "packed" thing has a special meaning.  I can't quote you from the
> ANSI or ISO standards offhand, but the idea is that the compiler is
> supposed to arrange that the packed structure takes up a minimal amount
> of space (probably subject to some alignment restrictions).  So in the
> example I gave each boolean would take up one bit, and there would be
> 1024 of them, the whole array taking up 128 bytes.

The trouble is that a Pascal compiler is absolutely free to ignore
'packed' entirely.  When you say
    var a: array [0.1023] of boolean;
you have no guarantee at all that the compiler won't use 1024 "words".
To quote the Berkeley Pascal manual page:
    "The keyword 'packed' is recognized but has no effect."
You would be lucky to find a Pascal compiler which will pack array
elements down to the bit level.  Byte level, yes.

The situation is better in C for two reasons.
(1) At least you can say
    char a[1024];
    and get nothing worse than byte packing.

(2) You can write the bit-extraction operations as macros, and use them
    over and over again on different arrays.

And of course there are those C compilers which have the "inline"
processor, so that you can have
    get_bit(array, index)
and    put_bit(array, index, value)
turned into your machine's instructions for bit access.  (Yay, Sun!)

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Don't use Scanf()

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8362
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:34 AST
Received: by UWAVM (Mailer X1.25) id 5660; Sat, 12 Mar 88 12:33:35 PST
Date:         Fri, 11 Mar 88 17:53:52 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Pete Lyall <pete@wlbr.EATON.COM>
Subject:      Re: Don't use Scanf()
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1185@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes:
>One real stupidity I've seen many, many times is the
>over-use of printf.
>
>For example:
>    printf("Hello world!\n");
>Haven't you ever heard of puts????
>    puts("Hello world!");    /* note the newline is appended    */

Hmmmm. What about the case where 'printf()' is already used elsewhere
in the program for argument substitution and formatting? Wouldn't
this merely be just another subroutine (in RMA) call to the already
included 'printf' function? If that is in fact the case, the I would
suspect that the use of 'puts()' or 'fputs()' would actually add code,
unless of course the 'puts()' or 'fputs()' are used internally by
'printf()'. I doubt that this is the case (my local unix.wizard says
the 'puts' brothers aren't used by 'printf()', at least not here).

Another item you might consider... if you're using a coco3 under level
II, the minimum allocation segment is 8k under the memory management
scheme. Os9 doesn't care if the program is 79 bytes or 7900 bytes, it
is still going to allocate 8192 for the program segment (or some
multiple thereof). Of course the counter arguments are that if you're
byte-fighting to get within the next lower 8k notch, removal of *all*
printf's may do you some good (approximately 3-5k).  Also, you could
save some disk space by removing *all* printf's.


--
Pete Lyall (OS9 Users Group VP)|  DELPHI: OS9UGVP  |  Eaton Corp.(818)-706-5693
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
Internet: pete@wlbr.eaton.com      UUCP: {ihnp4,scgvax,jplgodo,voder}!wlbr!pete

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: sizeof(char)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8371
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:35 AST
Received: by UWAVM (Mailer X1.25) id 5676; Sat, 12 Mar 88 12:33:42 PST
Date:         Fri, 11 Mar 88 11:22:58 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Rahul Dhesi <dhesi@bsu-cs.uucp>
Subject:      Re: sizeof(char)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Ray Butterworth:
     Other than allowing sloppily written code to continue to be
     written, I can see no reason whatsoever for requiring that
     sizeof(char) be 1.

Doug Gwyn:
     Yes!  I would appreciate it if you would send in a comment...

Please don't do this.  Code that conforms to K&R should not be called
sloppy.  From page 126:

     The size is given in unspecified units called "bytes," which are
     the same size as a char.

Existing code will break if sizeof(char) != 1, and let's not blame the
programmer for simply taking K&R at face value.  And nowhere do I find
K&R saying that byte == char == 1 unit is simply a compiler peculiarity
and not a design assumption in the language.  I have always believed,
and I'm sure others share this reasonable belief, that the C
programming language is defined by all of K&R, and not just by the
brief semi-formal reference manual in the back of the book.

I think "long char" is a better bet than changing the meaning of
"char".  Simply making "char" into two bytes will not allow
new code, that needs long characters, to be usable with old compilers
anyway.  So there is no great need to continue to use the type "char"
for long characters (and it could be deceptive to do so).  With "long
char" one would simply need a new set of str functions such as
lstrcmp(), lstrcpy(), etc.  So long as we need long chars, and also
wish to permit short chars to be used for storage economy, we cannot
avoid having two sets of string functions anyway.

There is precedence for this sort of change in seek() going to lseek().
--
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  syntactical convenience

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8379
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:35 AST
Received: by UWAVM (Mailer X1.25) id 5692; Sat, 12 Mar 88 12:33:49 PST
Date:         Fri, 11 Mar 88 19:07:00 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Bear with me <kruger@whyvax.dec.COM>
Subject:      syntactical convenience
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

It's minor either way, but syntactically, it would be nice if you could
define a bunch of same-sized bitfields in one shot. For example:

struct
{
  bit(1) x,y,z;
}

The current system does not convey the meaning as clearly, and is longer and
more obnoxious. Of course, it's only an inconvenience either way.

A more important addition, and a surprising lack in the standard, is the
preprocessor, which doesn't allow inserting preprocessing directives. Our
standards rep had no good arguments against adding the capability, which is
no harder to implement and breaks no programs. He simply said it was unlikely
to change at that point -- not very satisfying.

An example of what I am referring to is:

#define TBD    #error



/* this code is not complete yet */
TBD


Of course, this is not the only use of this feature. It is even more surprising
that recursive definitions are not permitted -- the line has to be rescanned
anyway, and it's just as much work. Ah well....

dov

Disclaimer: Your mileage may vary. Void where prohibited. Weight is before
cooking. Digital is not to be held responsible for my madness.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: How not to write a loop

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8423
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:39 AST
Received: by UWAVM (Mailer X1.25) id 5718; Sat, 12 Mar 88 12:38:31 PST
Date:         Fri, 11 Mar 88 06:21:22 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "James E. Prior" <jep@oink.uucp>
Subject:      Re: How not to write a loop
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <402@osupyr.UUCP> gae@osupyr.mast.ohio-state.edu.UUCP (Gerald Edgar)
 writes:
>Lengthy discussion about loops such as:
>
>>>>     float x;
>>>>     for (x = 0; x < 20; x += .5) printf("%f\n", x);
                          ^
                          A decimal point would have been nice!
>
>How about this:
>
>     float x;
>     for (x = 0; x < 19.75; x += .5) printf("%f\n", x);

Yes, this will work reliably across many machines.  However, your
suggested solution causes another problem, obfuscation of the intended
end value of the loop.

I realize that 19.75 is half the increment less that twenty, but
someone else might not have that much insight.  You should right
your code so that it is obvious how the magic number 19.75 is
derived.

Next step in obviousness:

    for (x=0; x<20.-.5/2.; x+=.5) ...

but even now, it is not clear that the .5 in 20.-.5/2. is the same
5 as in x+=.5.  The next step in obviousness is:

#define STEP (.5)
    for (x=0; x<20.-STEP/2.; x+=STEP) ...

This is quite handy for someone who never saw the <20 to begin with.
With the way you wrote your solution, someone needing to change the
step to .25 could inadvertently re-introduce reliability problems as
follows:

    for (x=0; x<19.75; x+=.25)

Another step to de-mystify 20. would be nice.

I stronly recommend that you read Elements of Programming Style by
P. J. Plaugher.  You have reinforced one of the reasons I quit OSU.

>  Gerald A. Edgar                               TS1871@OHSTVMA.bitnet
>  Department of Mathematics                     gae@osupyr.UUCP
>  The Ohio State University  ...{akgua,gatech,ihnp4,ulysses}!cbosgd!osupyr!gae
>  Columbus, OH 43210                            70715,1324  CompuServe
--
Jim Prior    {ihnp4|osu-cis}!n8emr!oink!jep    jep@oink.UUCP

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Re: ANSI C idea: structure literals (and short constants)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8434
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:39 AST
Received: by UWAVM (Mailer X1.25) id 5734; Sat, 12 Mar 88 12:38:38 PST
Date:         Fri, 11 Mar 88 04:10:06 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Dave Decot <decot@hpisod2.HP.COM>
Subject:      Re: Re: ANSI C idea: structure literals (and short constants)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> decot@hpisod2.HP.COM (Dave Decot) wrote:
> >The problem of deciding what their type is solved for now (and possibly
> >always) by stating in the standard that such syntax has no inherent type
> >and must be cast or assigned to the desired type.
>
> They're not, but the point is that this is a totally new meaning for a
> cast.  Usually, a cast is a unary operator.  Here, it's part of the
> description, like a declaration.

No, I intend that as far as the language is concerned, {...} is an expression
that has a value, but there are only two operations defined on such values:
assigning it to an lvalue using '=', or casting it to the appropriate
aggregate type.

This concept is somewhat the cousin of (void *), which generates pointers to
values that are not usable directly; such pointers must be cast to some
other pointer type before the object to which they point can be used.

> To be specific: "(int)f" is an
> expression that gets an int-ish value for the floating expression f.
> It doesn't change f.

Depends on what you mean by "f".  This cast changes the bit pattern
used for representing the value, surely.   Pointer casts change the
type of the value to which the expression points, which may give them
a completely different abstract interpretation.

> In your proposal, (struct a){...} and (struct b){...} imply different
> values for {...}.

What do you mean by "different values"?  Of course they are different,
they're of different types!  If you mean "bit patterns", this is also
true of your cast example above.

Anyway, this same syntax represents the same type of typeless value
that could be said is used for initializers; the value of these
depends on the type of the variable which it initializes.

> This is very inconsistent, even worse than the inconsistencies
> between casting pointers and casting numerical types.

It's more similar to casting numerical types than casting pointers,
and I think it should be, in order to make these things look like
constants.

> Also, your (struct ..) cast will produce an lvalue,
> which is also a big inconsistency.

That is a misinterpretation, and I'm not sure how you arrived at it.
Cast only produce rvalues; I assumed this would be obvious.

Dave Decot
hpda!decot

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: I forget what it was originally called.

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8466
          for SXJVK@ALASKA; Sat, 12 Mar 88 11:43 AST
Received: by UWAVM (Mailer X1.25) id 5770; Sat, 12 Mar 88 12:43:11 PST
Date:         Thu, 10 Mar 88 19:37:44 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was news@unmvax.unm.EDU
From:         "Michael I. Bushnell" <mike@turing.UNM.EDU>
Subject:      Re: I forget what it was originally called.
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <3623@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr)
 writes:
>Which brings me to another question:  How good are compilers these
>day?  Can they optimize just as well as a programmer (without
>resorting to assembly, that is) or not?  For example:

Actually, optimizing C and FORTRAN compilers nowadays do better than
programmers writing in assembly language.  There goes another old
misconception...

>A)
>temp = {expression}
>a[temp] = 1;
>b[temp] = 2;
>c[temp] = 3;

>B)
>a[temp={expression}]=1;
>b[temp]=2;
>c[temp]=3;

>C)
>a[{expression}]=1;
>b[{expression}]=2;
>c[{expression}]=3;

>A) is very readable.  B) may or may not be slightly faster.  Does
>anyone know whether B) is typically faster than A)?  Would it probably
>generate the same code?  C) is slower since {expression} is evaluated
>three times, *unless* the compiler knows to evaluate it once and put
>it in a register.  Which may be about the same thing as what A) and B)
>are doing, *except* in A) and B) it might will write the value into a
>variable, which is slower than storing it in a register.  Of course,
>there's always:

Actaully, I find (B) to be more readable, but that isn't what you were
concerned about.  B is just as fast as A on any optimizing compiler.
C is also equal.  However, if the expression has a potential side
effect (like a function call), but you know there aren't any real side
effects, then C can't be optimized and will prove a little slower.
The Gnu C compiler will take (C) (assuming no potential side effects)
and calculate expression once, and store it in a register.  Pretty
neat, huh?

>D)
>{
>register temp;
>temp = {expression};
>.
>.
>.
>}
>But I find this harder to read, and furthermore, since C compilers can
>ignore register declarations anyway, it might put it in as a normal
>variable (just like A) ), but it will slow down because it's allocated
>each time through the block of code.

A compiler is allowed to ignore the decalaration, yes.  But if you
have a compiler that does, you are entitled to your money back.  It is
a little like the air IP link:  no packets transmitted, but, they did
say the protocol was nonreliable, right?
It is a little harder to read, and usually won't get you much.  If the
compiler ignores the register spec, however, you won't have any
problem with wasting time pushing and popping stack frames:  simple
peephole optimization will generate code equivalent to declaring it as
a variable specific to the function as a whole.  It is usually, I
think, a little slower to declare it static, but that is heavily
architecture dependent.


                Michael I. Bushnell
                mike@turing.unm.edu
                {ucbvax,gatech}!unmvax!turing!mike

                HASA -- "A" division

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Don't use Scanf()

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8626
          for SXJVK@ALASKA; Sat, 12 Mar 88 12:38 AST
Received: by UWAVM (Mailer X1.25) id 5868; Sat, 12 Mar 88 13:38:07 PST
Date:         Sat, 12 Mar 88 08:15:49 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was nobody@sunybcs.uucp
From:         Fai Lau <ugfailau@sunybcs.uucp>
Subject:      Re: Don't use Scanf()
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1185@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes:
>One real stupidity I've seen many, many times is the
>over-use of printf.  The printf functions have their uses,
>and they do their job quite well, but please know what these
>uses are!!

    C'mon!!! Is it really an issue?

>For example:
>    printf("Hello world!\n");
>Haven't you ever heard of puts????
>    puts("Hello world!");    /* note the newline is appended    */

    I can't imagine any reasonably competant C compiler not
generating the almost same codes for both cases.

>or
>    printf("hi");
>try fputs:
>    fputs("hi", stdout);    /* no newline appended    */
>What's that?  Oh, now you have to include <stdio.h> so
>you can get the proper declarations of all these functions anyway?
>Poor baby!

    <stdio.h> should be included in mostly every program
just so that when you do need it you have it around. It's not
gonna give you a bigger or slower program.

>And the ultimate stupidity:
>    printf("\n");
>Get a brain!!!!!  You're using the function that can do complex
>data formatted output to write one bleeping character!!!!!
>Try
>    putchar('\n');
>If you include <stdio.h>, this will probably end up being a macro
>that will write it out very fast.
>
>I have even seen:
>    sprintf(buf, "constant string");
>Hey, Mr. Power-Programmer, ever heard of strcpy????

    Let's face it. The best way to give efficiency to a program
is to write your own macro to handle file I/O and strings. Macros like
strcpy are too general if you want to be picky.
    For example, if you want to print a string fast, you would write
a routine that uses only putc with no format capacity and no error
checking whatsoever, and forget about printf. Most of what you
said are true. But if one has to be as picky as you suggest, then
let's forget about stdio.h and strings.h and write everything from
the ground up.

Fai Lau
SUNY at Buffalo (The Arctic Wonderland)
UU: ..{rutgers,ames}!sunybcs!ugfailau
BI: ugfailau@sunybcs INT: ugfailau@joey.cs.buffalo.EDU

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8854
          for SXJVK@ALASKA; Sat, 12 Mar 88 14:12 AST
Received: by UWAVM (Mailer X1.25) id 5927; Sat, 12 Mar 88 15:11:05 PST
Date:         Sat, 12 Mar 88 06:13:45 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was news@sigi.Colorado.EDU
From:         Frank Swarbrick <swarbric@tramp.Colorado.EDU>
Subject:      Re: Pascal --> C question
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Hey, I've got no problem with having a 'bit' data type!  I've been wondering
why it doesn't exist already.  It seems rather silly for boolean values
to take up a whole byte.

But I'm sure there is a good reason for this.  (There is, isn't there?  :-)

Frank Swarbrick (and his cat)
swarbric@tramp.UUCP               swarbric@tramp.Colorado.EDU
..!{hao|nbires}!boulder!tramp!swarbric
"Welcome back my friends to the show that never ends..."

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  cpp.c desperately needed

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9022
          for SXJVK@ALASKA; Sat, 12 Mar 88 15:13 AST
Received: by UWAVM (Mailer X1.25) id 5954; Sat, 12 Mar 88 16:13:21 PST
Date:         Sat, 12 Mar 88 11:04:41 ITA
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     CROSSNET mail via SMTP@CUNYVM
From:         MH9TS1BF%ICINECA.BITNET@CUNYVM.CUNY.EDU
Subject:      cpp.c desperately needed
Comments: To: Info-C@BRL.ARPA
To:           Vic Kapella <SXJVK@ALASKA>


From a desperate Fortranist, who put himself into troubles
with his own hands.

Dear C Community,
Can anybody help me ? I have a lot of Fortran source code
to be preprocessed by cpp (to handle machine dependencies etc)
( it seemed a good idea ... )
that I am porting from a Unix environment to Vax/VMS.
The Digital Vax C compiler we have on our 8800
has a built-in cpp which cannot be used stand-alone !
i.e. I cannot avoid my poor Fortran programs to be fed into
the subsequent passes of the C compiler ( hard work for
the parser ..).
Does anybody know if there is a cpp.c in the public domain, and
how to reach it ?

Thank you very much in advance to anybody who may help me.

Furio Ercolessi, Intl. School for Advanced Studies, Trieste (Italy)
     MH9TS1BF@ICINECA.BITNET

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: The D Programming Language

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9296
          for SXJVK@ALASKA; Sat, 12 Mar 88 16:52 AST
Received: by UWAVM (Mailer X1.25) id 6030; Sat, 12 Mar 88 17:52:24 PST
Date:         Sat, 12 Mar 88 01:56:28 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Scott Daniels <daniels@teklds.TEK.COM>
Subject:      Re: The D Programming Language
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <587@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes:
>Another example is string comparison.  I use a string compare function
>that returns the index of the first different character.  I also
>need the gt/lt/eq result.  Fortunately, in this case it is easily
>computed by recomparing the chars at the index.

An alternative is the string comparison I normally use:

    cmpstr(s1,s2)
0: if equal
>0: if s1 > s2
<0: if s1 < s2

abs(cmpstr(s1,s2)) is the number of chars compared:
  s1[ abs(cmpstr(s1,s2))-1 ] != s2[ abs(cmpstr(s1,s2))-1 ]
  if cmpstr did not return 0.  Normally this function returns just
  about any information I need, and it is usually not very hard to
  make an extremely fast version in assembly.

-Scott Daniels (daniels@teklds.TEK.COM)

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: The need for D-scussion (was Re: D Wishlist)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9347
          for SXJVK@ALASKA; Sat, 12 Mar 88 17:04 AST
Received: by UWAVM (Mailer X1.25) id 6069; Sat, 12 Mar 88 18:03:38 PST
Date:         Fri, 11 Mar 88 21:52:38 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Henry Spencer <henry@utzoo.uucp>
Subject:      Re: The need for D-scussion (was Re: D Wishlist)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> >Most of the things on this wishlist
> >are incompatible but unimportant.  (Not trivial, necessarily...
>
> I disagree that the items on the wishlist are unimportant.  True
> multidimensional arrays, better bit-level data support, a general
> aggregate constructor mechanism, a better declaration syntax, and a
> more general macro facility are *major* improvements...

Au contraire.  All they do is reduce the clumsiness of doing those
things in C.  While that is certainly useful, it is not going to sell
people on a new and incompatible language.  To do that, you need to
show an order-of-magnitude improvement -- overall, not just in a few
narrow areas.  The things you have listed above are all just icing on the
cake; they would *help* sell a language that was already a real contender
for other reasons, but by themselves they aren't enough.  (Analogously,
C++ includes a number of useful, nice small improvements on C, but it
would not be worth the trouble without its abstract data types and
object-oriented type system.)

> I'm sorry, but I just don't think C++ is so good that a *much* better
> language is not possible...

Oh, I agree it's *possible*; my point is that I don't know how to do it.
A little better, yes, that I could do.  Fifteen years of active interest
in language design, and considerable private work on ideas about the
ideal programming language, has given me more than enough thoughts on
ways to improve C.  But most of them would be, indeed, just icing.  My
conclusion, after a lot of thought, is that it doesn't matter how much
icing you put on if there's no cake underneath.  I don't know how to
get the order-of-magnitude improvement needed to make lots of converts.
That requires at least one quantum leap upward in the power of the language,
not just incremental improvements and smoothing down the rough edges.
--
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Re: ANSI C idea: structure literals (and short constants)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9355
          for SXJVK@ALASKA; Sat, 12 Mar 88 17:05 AST
Received: by UWAVM (Mailer X1.25) id 6084; Sat, 12 Mar 88 18:03:46 PST
Date:         Fri, 11 Mar 88 21:29:56 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Henry Spencer <henry@utzoo.uucp>
Subject:      Re: Re: ANSI C idea: structure literals (and short constants)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> I fail to see that the committee has drawn and observed "need" as
> a clear boundary for what should be standardized.

They have tried.  Sometimes they've let their enthusiasm run away with
them; these are reprehensible lapses that should not be considered an
excuse to others to do likewise!

> > [expletive deleted]  Speaking as a user and an implementor, this is an
> > abortion if there ever was one.
>
> Thank you for the feedback.  But I wonder if you would be so kind as to
> elaborate on this comment...

*Why* introduce a new notion of something that doesn't have a type (actually
it does have a type, some sort of curious mix of the types of the things
inside it) when it is easy to invent a syntax (or borrow the one from the
GNU compiler) that specifies the type?!?

> > ... probably the GNU compiler's approach, which avoids this
> > hideous botch entirely.
>
> I wonder if you would mind summarizing that approach for those of us who
> don't have access to that compiler's source code.

As I recall it -- I have not studied the GNU compiler closely yet -- the
technique used is a sort of "cast with an initializer".

> At any rate, your comment seems to imply that this is existing practice,
> so I am having trouble seeing why this is a topic that should not be
> standardized.

"Existing practice" means that it has been out there for a while, that
people other than its implementors have used it at some length, and that
it has been used for more than just toy programs.  That does not happen
overnight, the GNU compiler is very new, and the draft standard is
(theoretically) in virtually its final state.
--
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Portable "asm" <-- portable? since when?

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9420
          for SXJVK@ALASKA; Sat, 12 Mar 88 17:21 AST
Received: by UWAVM (Mailer X1.25) id 6114; Sat, 12 Mar 88 18:21:23 PST
Date:         Fri, 11 Mar 88 22:10:17 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Henry Spencer <henry@utzoo.uucp>
Subject:      Re: Portable "asm" <-- portable? since when?
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> If the #asm has to come back, let's just revert to the old K&R style:
>
>     #asm
>     ; assembly goes here
>     #endasm

What "K&R" style?!?  There is no "asm" or "#asm" in K&R.  (It is mentioned
once, in the Reference Manual, as a keyword reserved by some compilers.)

> I *would* like to see the "interrupt" keyword added to ANSI C (or D).
> For a language to claim to be a system programming language and not
> provide the capability to write interrupt routines is a major oversight
> (although K&R seemed to do fine without it :-)...

This is a curious statement, given that all Unix's interrupt routines are
written in C.  There is a little bit of assembly-language glue involved
on most machines, but all that does is smooth over differences in calling
conventions.  If you are willing to live with the idea that you can't
just plop a function's address into an interrupt vector, but some small
amount of mediation is required, no language change is necessary.  It's
not as if what you were doing was portable and could usefully be made
standard across different implementations.  (If you think it is, consider
for example that my machine's interrupt vectors are structures, not just
single pointers, so just filling in a function pointer is not enough.)

> Also, I would like to see named access to specific CPU registers included
> in ANSI C, e.g. AX, BX, R0, R1, etc...

Subject to certain rules about naming conventions, ANSI implementations
are free to provide whatever machine-dependent magic cookies they want.
So are non-ANSI implementations, for that matter.  Complain to your vendor
if he doesn't do what you want.  Actually *specifying* what should be
done is so hopelessly machine-dependent and implementation-dependent that
no standards committee in its right mind would put it into a standard.
--
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pointers to functions

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9440
          for SXJVK@ALASKA; Sat, 12 Mar 88 17:25 AST
Received: by UWAVM (Mailer X1.25) id 6131; Sat, 12 Mar 88 18:25:24 PST
Date:         Fri, 11 Mar 88 22:15:28 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Henry Spencer <henry@utzoo.uucp>
Subject:      Re: Pointers to functions
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> The idea to have the same pointer arithmetic on labels as on pointers to
> functions seems to be a good one (in my opinion)...

X3J11 supports this view entirely, since neither is allowed to participate
in arithmetic in any way.  This is a practical necessity; on some machines,
pointers to functions are very strange "magic cookies" whose contents don't
even slightly resemble pointers to data, and pointers to random spots in
the code basically don't exist.

> ... Secondly this would allow additional entry points into functions.

Some machines cannot do this, period.  It's also not at all clear that it
is particularly useful, which is probably why nobody ever did anything
with the "entry" keyword.
--
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: ANSI C idea: structure literals (and short constants)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9636
          for SXJVK@ALASKA; Sat, 12 Mar 88 19:31 AST
Received: by UWAVM (Mailer X1.25) id 6173; Sat, 12 Mar 88 20:31:21 PST
Date:         Sat, 12 Mar 88 07:06:28 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Peter da Silva <peter@sugar.uucp>
Subject:      Re: ANSI C idea: structure literals (and short constants)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article ... henry@utzoo.uucp (Henry Spencer) writes:
>     foo = { ... };

> It is agreed that the latter form is more convenient.  But we were talking
> about *needs*, in the context of an existing language, not about a wishlist
> for a new language.

I implemented just this construct in a copy of the Small-C compiler I was
playing around with about 6 years ago. I had just picked up a copy of the
BCPL book and wanted to play with the concepts.

I also implemented this:

    foo = { for(i = 0; i < 10; i++) if(...) break; i; };

in analogy to the BCPL:

    foo = $( ... resultis i; $)

Back to the subject.. the problem of what type an aggregate constant is
is a lot easier in Small-C. It's only got 4 types. But if you need prior art
to consider this, well here's two examples (half-smiley).

> way to do it is probably the GNU compiler's approach, which avoids this
> hideous botch entirely.

What's the GNU compiler's approach?
--
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Header problems

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 9841
          for SXJVK@ALASKA; Sat, 12 Mar 88 21:05 AST
Received: by UWAVM (Mailer X1.25) id 6269; Sat, 12 Mar 88 22:04:47 PST
Date:         Thu, 10 Mar 88 16:07:15 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         SIEMON <mls@whutt.uucp>
Subject:      Re: Header problems
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <3416@chinet.UUCP>, dag@chinet.UUCP (Daniel A. Glasser) writes:
>
> ...
> In other words, though proper usage uses casts on NULL, common usage
> does not.
>
>         Daniel A. Glasser    dag@chinet.UUCP

Yes; you should realize that you were flamed so much because people were
feeling deeply guilty about their own failure to practice what they preach.
Here was a perfect scapegoat -- someone who could be read as not understanding
what to do and could be lectured about it by those who REALLY intend to do it
right, but somehow don't quite get around to it.  (Please no flames from those
who really do go to the effort to do it right -- you are a rare breed; for
most of us, it is just too damned easy to "code" and too damned hard to think
and to rewrite.

Michael Siemon
contracted to AT&T Bell Laboratories
(these are my opinions, not theirs)
ihnp4!mhuxu!mls

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Constant overflow

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0287
          for SXJVK@ALASKA; Sat, 12 Mar 88 23:22 AST
Received: by UWAVM (Mailer X1.25) id 6326; Sun, 13 Mar 88 00:21:41 PST
Date:         Sun, 13 Mar 88 05:24:50 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was news@husc6.harvard.EDU
From:         Kaufer - Lopez - Pratap <steve@endor.harvard.EDU>
Subject:      Re: Constant overflow
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

Here is the output from the Saber-C programming environment:
(Running on SUN & VAX,  Ultrix/Unix):

                        Saber-C - Version 1.2c
        Copyright (C) 1986, 1987, 1988 by Saber Software, Inc.

Attaching: /lib/libc.a
1 -> load("foo.c");
Loading: foo.c
----------------
"foo.c", line 2: Integer too large (Warning #220)
    1: /* Sample overflow */
    2: long i = 9876543210L;
                ^
    3:
Integer constant (9876543210) exceeds maximum unsigned long (4294967295).
Options: continue/suppress/terse/quit/abort/edit/reload [c] ?

    Stephen Kaufer
    Saber Software, Inc.
    saber@harvard.harvard.edu
    30 JFK Street, Cambridge, MA.  02138
    (617) 876-7636

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Re: Constant overflow

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0359
          for SXJVK@ALASKA; Sat, 12 Mar 88 23:48 AST
Received: by UWAVM (Mailer X1.25) id 6413; Sun, 13 Mar 88 00:47:52 PST
Date:         Fri, 11 Mar 88 11:47:41 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Alan_Rooks_sps <alan@bk.dk>
Subject:      Re: Re: Constant overflow
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <2550059@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes:

>It's hard to do this right unless you do some clever comparison
>just before multiplying by 10 (or 8 or 16 or 2).

A proven (and very simple) way to do this right was given by J. R. Parker in
"A General Character to Integer Conversion Method", Software - Practice and
Experience, Vol 15(8) (August '85), pp. 761-766.

Alan Rooks - Bruel & Kjaer Copenhagen - ...!mcvax!bk!alan or ...!diku!bk!alan

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0369
          for SXJVK@ALASKA; Sat, 12 Mar 88 23:49 AST
Received: by UWAVM (Mailer X1.25) id 6429; Sun, 13 Mar 88 00:49:35 PST
Date:         Fri, 11 Mar 88 04:19:24 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Andrea Humenick <cs2531ar@charon.unm.EDU>
Subject:      Re: Pascal --> C question
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <4766@sigi.Colorado.EDU> swarbric@tramp.Colorado.EDU (Frank
 Swarbrick) writes:
>Or does the "packed" thing in Pascal have some special meaning?  I never could
>figure out what the difference between a packed array and a regular array was.

I'm a new poster, so I'm sorry if this is improper.

In my current pascal class my teacher explained packed and not packed as
this

        packed:   an array that can read in '       '
    not packed:   an array that can only be read in character by character

thank you.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Long Chars

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0538
          for SXJVK@ALASKA; Sun, 13 Mar 88 01:06 AST
Received: by UWAVM (Mailer X1.25) id 6525; Sun, 13 Mar 88 02:05:53 PST
Date:         Sat, 12 Mar 88 22:11:00 EST
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
Subject:      Long Chars
Comments: To: info-c@BRL.ARPA
To:           Vic Kapella <SXJVK@ALASKA>

(This discussion is looking for a good pun... like "lawn chairs"?  No... I
said GOOD pun.)

The "short char vs char" problem can't be solved very easily.  Why not a
"long char".  That wouldn't break much code now, would it?  Now I'm not
demanding that it goes into v1.0 of the standard but maybe we can look at
this for the next "congress".

For now, if you want to make some progress, try to get one of the biggies
(like MS) to add it as an extension.  You can tell them that they'll hit
on the "multi-nation/multi-language vendor market" with it.

Of course, in my programming I don't have a use for it, but if you do, try

typedef short LONG_CHAR;
or
typedef char LONG_CHAR[2];
(Hmmm... I like the former)

and then you can implement a lstrcmp() and a lstrcpy() and an assortment
of routines like that.  Then when you're done, those can be re-used in all
your programs.

When it get's suggested to ANSI C II (or whatever it'll be called) you'll
be there to warn us about implementation difficulties and ideas.  And when
it gets passed you can do a search-and-replace from "LONG_CHAR" to "long
char"

"And there was much rejoicing" -- Monty Python


Tom Limoncelli | Drew U/Box 1060/Madison NJ 07940 | tlimonce@drew.BITNET
    Disclaimer: These are my views, not my employer or Drew Univesity
--------------------------------------------------------------------------

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0551
          for SXJVK@ALASKA; Sun, 13 Mar 88 01:10 AST
Received: by UWAVM (Mailer X1.25) id 6542; Sun, 13 Mar 88 02:10:14 PST
Date:         Sat, 12 Mar 88 21:53:00 EST
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
Subject:      Re: Pascal --> C question
Comments: To: info-c@BRL.ARPA
To:           Vic Kapella <SXJVK@ALASKA>

On 12-MAR-1988 09:06 ok@quintus.uucp wrote:

>You would be lucky to find a Pascal compiler which will pack array
>elements down to the bit level.  Byte level, yes.

Actually, the only version of Pascal that I will use is VaxPascal under
VMS (what's that?) because it has some execelent optimizations.  First of
all, it does wonders with PACKED arrays and variables.  Unpacked BOOLEANs
take up the same as a INTEGER (4 bytes/1 word) so that you have maximum
speed but PACKED ARRAY [xx..yy] OF BOOLEAN is packed to the bit-level.
VaxPascal will also do optimizations like not recalculating x+1 each time
it's used.  (This next one addresses anyother info-c debate)  It will even
attempt to make functions and procedures inline if it can determine that
it is not recursive (or any other problems) and if it will save
memory/time.

Best of all, all of the optimizations and run-time checking can be turned
on or off easily.  I do super-fast compiles that generate slow, bulky code
until I know it all works.  Then I do PASCAL/OPTIMIZE=ALL/CHECK=NONE and
let it take all the time it wants to make my final product.

Why can't popular C compilers do that?  (Whoa!  Maybe I should ask, "Which
ones do that NOW?" ?)

Actually, from what I read, we are on the brink of seeing more and more
optimizers on the market very soon.  All that grad-school work on writing
faster compilers is finally feasible now that we all have our wiz-bang
machines based on 386s and '030s (yeah right!  Lemme win the lottery first!)


Tom Limoncelli | Drew U/Box 1060/Madison NJ 07940 | tlimonce@drew.BITNET
    Disclaimer: These are my views, not my employer or Drew Univesity
--------------------------------------------------------------------------

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  powerC review

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0582
          for SXJVK@ALASKA; Sun, 13 Mar 88 01:33 AST
Received: by UWAVM (Mailer X1.25) id 6586; Sun, 13 Mar 88 02:30:47 PST
Date:         Sat, 12 Mar 88 11:53:06 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Stanley M. Sutton" <sms@sugar.uucp>
Subject:      powerC review
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

I purchased power C about a month ago.  For the most part, I like it a
lot.  The manual that comes with the compiler is worth more than the $20
they are asking for the compiler.  Any of you that used Mix C on CP/M or
MSDOS will be familar with the book.  It's been expanded for ANSI C, and
a MSC 4.0 /TC 1.0 compatable library.  It has a relatively fast
compiler/linker. I've used quick C and Turbo C at work on similar programs (Not
identical, so it is not really benchmarking) and they all seem to be within
10% of each other.

However, there are some problems.  I can't compile microEMACS with power
C.  It apparently runs out of heap in the optimizing phase.  Mix
Software says they are working on changing the compiler to use far heap
instead of near heap, but it is a complicated conversion, so don't
expect it before 3rd quarter 88.  It does not always use the environment
strings properly to control the compilier/linker.  An example is SET
PCOPTION=/O\C:\C\MIX\ to put objects into a libary.  Instead of
overiding the object location if it is respecified on the compilier
line, the line specification is appended to options string
specification.  This is not what the manual says it does, but is useful
if you are maintaining a multi-level directory of source, and want to
maintain the same structure with object.  Also, most of the environment
problems can be solved by using DOS 3.3 APPEND commands.

Just recently I've run into a problem with bit fields in a structure not
working correctly.  It works fine for simple cases (i.e., if I simplify
the problem, it goes away).  However, in the Dr. Dobbs journals "C Chest
and Other Treasures" routine getargs, they don't work.  I'm planning on
shipping off a disk this weekend to see what Mix Software thinks of it.

To summarize, Good points:
    inexpensive
    good manual
    good user support
    good libary functions

Bad points:
    bit fields don't always work
    some environment string problems
    large programs may not compile


One additional comment.   The manual for the Power Ctrace source
debugger was shipped to the printer at the beginning of March, so they
expect to begin selling and shipping around the first of April.  I've
used the Mix Ctrace, and liked it as a multi-windowed source level
debugger.  I expect Power Ctrace to be similar.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Constant overflow

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0614
          for SXJVK@ALASKA; Sun, 13 Mar 88 01:38 AST
Received: by UWAVM (Mailer X1.25) id 6629; Sun, 13 Mar 88 02:38:29 PST
Date:         Sat, 12 Mar 88 23:52:23 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Rafael Llave <llave@phoenix.Princeton.EDU>
Subject:      Re: Constant overflow
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <2550059@hpisod2.HP.COM>, decot@hpisod2.HP.COM (Dave Decot) writes:
 > Try this one on your favorite C compiler.  So far, every one I've tried
 > (including lint) has had no complaint:
 >
 >     long i = 9876543210L;
 >
 > (The problem, of course, is that that number doesn't fit in 32 bits...)

Integer arithmetic is not supposed to overflow and all
integers are  supposed to be taken ss defined modulo a power of 2 which
is implementation dependent. I have seen
some compilers that at compile time gave you warnings - God
bless them -- but to ensure portability of programs that
have to handle  occasionally large numbers , I have always
included some defensive lines.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Pascal --> C question

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0681
          for SXJVK@ALASKA; Sun, 13 Mar 88 02:00 AST
Received: by UWAVM (Mailer X1.25) id 6710; Sun, 13 Mar 88 02:59:06 PST
Date:         Sun, 13 Mar 88 00:20:21 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Rafael Llave <llave@phoenix.Princeton.EDU>
Subject:      Re: Pascal --> C question
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

#
# Except that the useful ones are never that easy.  One of my favorites:
#     bitstring: packed array[0..1023] of boolean;
# In C you have to do bit-fiddling by hand to get the same effect.
#

Many Pascal compilers ignore packed

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Why he won't use ANSI C

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0689
          for SXJVK@ALASKA; Sun, 13 Mar 88 02:00 AST
Received: by UWAVM (Mailer X1.25) id 6727; Sun, 13 Mar 88 02:59:13 PST
Date:         Sun, 13 Mar 88 00:01:49 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Rafael Llave <llave@phoenix.Princeton.EDU>
Subject:      Re: Why he won't use ANSI C
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

# Well, what about the fact that:
#
#     typedef int    (*PFI)();
#
#     main()
#     {
#         PFI    fp = main;
#     }
#
# gives:
#     fp == *fp == **fp == ***fp ?

A)
    It does not.
B)
    If it did , it would not be more serious
than
    for( i=0;;)
generating an endless loop.

jejones@mcrware.UUCP (James Jones) (03/13/88)

In article <12319@brl-adm.ARPA>, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU writes:
> Subject:  Re: Why NULL is 0
> 
> [Non-Deliverable:  User does not exist or has never logged on]

Huge quantities of messages that say "Undelivered mail" have started appearing
in comp.lang.c.  I can't help but wonder whether something somewhere (at CUNY?
on BITNET?) is broken.  Anyone have any theories?

		James Jones

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: nasty evil pointers

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1086
          for SXJVK@ALASKA; Sun, 13 Mar 88 05:42 AST
Received: by UWAVM (Mailer X1.25) id 7016; Sun, 13 Mar 88 06:41:42 PST
Date:         Sun, 13 Mar 88 05:37:25 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
Comments:     Warning -- original Sender: tag was news@husc6.harvard.EDU
From:         Kaufer - Lopez - Pratap <steve@endor.harvard.EDU>
Subject:      Re: nasty evil pointers
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1529@devvax.JPL.NASA.GOV> jackm@devvax.JPL.NASA.GOV (Jack Morrison)
 writes:
>In article <13100003@bucc2> brian@bucc2.UUCP writes:
>>
>>It would be nice if we could check every pointer as
>>it was used...
>
>Funny how often I see things in this newsgroup that can be answered
>with two words:
>    try Ada.
>
>Even funnier because I still prefer using C.
>
>-- Jack C. Morrison    Jet Propulsion Laboratory
---
Well, if you are still using C, you should really try an interpreter.
The Saber-C interpreter, from Saber Software, Inc., provides
full run-time checking of pointers (and many other nasty C things....)
More info can be obtained by e-mail or phone...

    Stephen Kaufer
    Saber Software, Inc.
    saber@harvard.harvard.edu
    30 JFK Street, Cambridge, MA.  02138
    (617) 876-7636

---
Note: As the address indicates, I work for Saber.
Having said that, comments about biased reporting to /dev/null!

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Don't use Scanf()

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1066
          for SXJVK@ALASKA; Sun, 13 Mar 88 05:36 AST
Received: by UWAVM (Mailer X1.25) id 7001; Sun, 13 Mar 88 06:35:20 PST
Date:         Sat, 12 Mar 88 14:00:25 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Johan Vromans <jv@mhres.mh.nl>
Subject:      Re: Don't use Scanf()
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <1185@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes:
>One real stupidity I've seen many, many times is the
>over-use of printf.  The printf functions have their uses,
>and they do their job quite well, but please know what these
>uses are!!
>
> [examples of using puts, fput, putc instead of printf]
>
>And the ultimate stupidity:
>    printf("\n");
>Get a brain!!!!!  You're using the function that can do complex
>data formatted output to write one bleeping character!!!!!
>Try
>    putchar('\n');
>If you include <stdio.h>, this will probably end up being a macro
.. If you don't you will likely end up with a missing routine ...
>that will write it out very fast.

Yes. But it does not flush if the output is a terminal or line-buffered.

>In general, if there's no format spec, don't use printf!!!!!!

I partly agree. When you are short on space, and want to eliminate the use
of "large" routines like printf, you are right.
On the other hand, you suggest the use of four or five different routines
(with all different calling sequences) instead of one simple and elegant
"printf" routine. Printf *CAN* do complex formatting, but it *DOESN'T* do
this if you don't have format strings. What remains is just the tiny
overhead of testing whether there are formatting characters in the string...

I dislike discussions in which the quality of the arguments is measured by the
number of exclamation marks following each sentence.


--
Johan Vromans                              | jv@mh.nl via European backbone
Multihouse N.V., Gouda, the Netherlands    | uucp: ..{uunet!}mcvax!mh.nl!jv
"It is better to light a candle than to curse the darkness"

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Benchmark - (nf)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1057
          for SXJVK@ALASKA; Sun, 13 Mar 88 05:35 AST
Received: by UWAVM (Mailer X1.25) id 6984; Sun, 13 Mar 88 06:34:24 PST
Date:         Fri, 11 Mar 88 14:03:00 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         LUC@SIEDAP
Subject:      Re: Benchmark - (nf)
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

/* Written  2:26 am  Mar  5, 1988 by news@brl-adm in siedap:comp.lang.c */
/* ---------- "Benchmark" ---------- */
This mail is intended for <kruger@16bits.dec.COM>, but I am posting
it to the list because the gateway burped at his numeric address.
-David-

----------------------------Original message----------------------------
Received: by WUVMD (Mailer X1.24) id 4182; Wed, 02 Mar 88 17:32:55 CST
Date:         Wed, 02 Mar 88 17:30:28 CST
From:         David Camp <C04661DC@WUVMD>
Subject:      Re: Dhrystones, anyone?
To:           "I've got 50nS memory. What did you say?" <kruger@16bits.dec.COM>
In-Reply-To:  Your message of Wed, 2 Mar 88 00:21:00 GMT

>I am interested in the Dhrystone, Whetstone, and other popular benchmarks.
>Please mail to me. If you want the collection, I will collect them and
>forward.
>
>Thanks!
>dov

I typed this in from a magazine.  I think it was "Computer Language",
but I am not certain.  I would appreciate your forwarding the collection.
-David-

*----------------------------------------------------------------------*
| (314) 362-3635                  Mr. David J. Camp                    |
|                          ^      Division of Biostatistics, Box 8067  |
| Room 1108D             < * >    Washington University Medical School |
| 706 South Euclid         v      660 South Euclid                     |
|                                 Saint Louis, MO 63110                |
| Bitnet: C04661DC@WUVMD.BITNET                                        |
| Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU                      |
*----------------------------------------------------------------------*

--------------------- FILE dhamp     c          ---------------------
--------------------------- cut here --------------------------------
/*      The dhampstone benchmark.  Written by Jack purdum. */
/*      version 1.0, August 1,1985                         */

#include "stdio.h"

#define BELL 7          /* ASCII BELL code */
#define FIB 24
#define TINY 100
#define MAXINT 179
#define LITTLE 1000
#define SMALL 9000
#define PRECISION .000001
#define FILENAME "zyxw.vut"
#define NUMTEST 6

#ifndef ERR
    #define ERR -1
#endif

struct
    {
    int cresult;
    int iresult;
    int cprsult;
    unsigned uresult;
    long lresult;
    double dresult;
    } results;

main()
{
char buf1[TINY], buf2[TINY];
int i = 0;
unsigned fib ();
long square, sq ();
double dmath, sroot (), dply ();

printf("Start...%c\n\n",BELL);
while (i < NUMTEST)
    {
    switch (i)
        {
    case (0):                                   /* Character test       */
        results.cresult = stest (buf1,buf2);
        printf ("\ncresult = %d\n",results.cresult);
        break;
    case (1):                                   /* Integer test         */
        results.iresult = intest ();
        printf ("\niresult = %d\n",results.iresult);
        break;
    case (2):                                   /* Unsigned test        */
        results.uresult = fib (FIB);
        printf ("\nuresult = %u\n",results.uresult);
        break;
    case (3):                                   /* Long test            */
        square = 0L;
        results.lresult = sq (square);
        square = sq (results.lresult);          /* Check the value      */
        printf ("\nlresult = %ld",results.lresult);
        printf ("\n square = %ld\n",square);
        break;
    case (4):                                   /* Double test          */
        results.dresult = sroot ((double) results.lresult);
        printf ("\ndresult = %f\n",results.dresult);
        dmath = dply (results.dresult);
        printf ("  dmath = %f\n",dmath);
        break;
    case (5):                                   /* Disk copy            */
        results.cprsult = mcopy ();
        printf ("\b   copy = %d",results.cprsult);
        break;
    default:
        break;
        }
    ++i;
    }                                           /* End while i          */
printf ("\n\n...End%c",BELL);
}

long sq (big)           /* Function to square a number by iteration */
long big;
{
int i;
static long j = 1L;

if (!big)
    for (i = 0; i < SMALL; ++i)
        {
        big += j;
        j += 2;
        }
else
    for (i = 0; i < SMALL; ++i)
        {
        j -= 2;
        big -= j;
        }
return (big);
}

double sroot (num)      /* Find square root of number */
double num;
{
double temp1, temp2, abs ();

temp2 = num / 2.0;
temp1 = num;
while (temp1 > PRECISION * temp2)
    {
    temp1 = (num / temp2) - temp2;
    temp1 = abs (temp1);
    temp2 = ((num / temp2) + temp2) / 2.0;
    }
return (temp2);
}

double abs (x)          /* Absolute value of a double */
double x;
{

return (x < 0 ? -x : x);
}

double dply (x)         /* Exercise some doubles */
double x;
{
int i = TINY;
double y;

while (i--)
    {
    y = x * x * x * x * x * x * x;
    y = y / x / x / x / x / x / x;

    y = y + x + x + x + x + x + x;
    y = y - x - x - x - x - x - x;
    }
return (y);
}

unsigned fib (x)        /* Common Fibonacci function */
int x;
{

if (x > 2)
    return (fib (x-1) + fib (x-2));
else
    return (1);
}

int stest (b1,b2)       /* String test using strcpy() and strcmp() */
char *b1, *b2;
{
int i,j;
void mstrcpy ();

for (i = 0, j = 0; i < SMALL; ++i)
    {
    mstrcpy (b1, "0123456789abcdef");
    mstrcpy (b2, "0123456789abcdee"); /* Note it's a different string. */
    j += mstrcmp (b1,b2);
    }
return (j);
}

int mstrcmp (c,d)       /* External string compare */
char *c, *d;
{

while (*c == *d)
    {
    if (!*c)
        return (0);
    ++c;
    ++d;
    }
return (*c - *d);
}

void mstrcpy (c,d)      /* External string copy */
char *c, *d;
{

while (*c++ = *d++)
    ;
}

int mcopy ()            /* Disk copy.  Test assumes file doesn't exist */
{
FILE *fp, *fopen ();
char buf[TINY];
int i, j;

mstrcpy (buf, "Disk I/O test");
if ((fp = fopen(FILENAME,"w")) == NULL)
    {
    printf ("Cannot open file");
    exit (ERR);
    }
i = 0;
while (++i < LITTLE)
    for (j = 0; buf[j]; ++j)
        putc (buf[j], fp);
fclose (fp);
return (i);
}

int intest ()           /* Square an integer by iteration */
{
int i, j, k, sum;

for (i = 0; i < LITTLE; ++i)
    {
    sum = 0;
    for (j = 0, k = 1; j < MAXINT; ++j)
        {
        sum += k;
        k += 2;
        }
    }
return (sum);
}

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  MSC 4.0 Internal Compiler Error

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1118
          for SXJVK@ALASKA; Sun, 13 Mar 88 05:54 AST
Received: by UWAVM (Mailer X1.25) id 7033; Sun, 13 Mar 88 06:53:33 PST
Date:         Thu, 10 Mar 88 16:15:20 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Markku Savela <msa@clinet.fi>
Subject:      MSC 4.0 Internal Compiler Error
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>


    I got the following message from my Microsoft C Compiler (4.0)
while trying to compile one of my programs (using LARGE MODEL and
MS-DOS):

    thisbug.C(8) : fatal error 1: Internal Compiler Error
        (compiler file 'regMD.c', line 272)
        Contact Microsoft Technical Support

    Here is a much reduced (and stupid) program fragment which still
produces the same result:

    int x,y,i;
    struct MemCell {int Ntype; struct MemCell *Mem} MemLoc[1000];

    void grokit()
    {
        while (i++ < 10) MemLoc[y].Mem[i] = MemLoc[x];
    }

    It seems that the following things are required
    - LARGE MODEL (compiles using SMALL)
    - loop (while, for,...)
    - Mem is not the first field of the structure
    - and of course this double indexing...

    I do not expect any help on this. I surely can code around the
problem. I'm just reporting a bug for anyone interested (whether
this reaches Microsoft or not, I don't care).  (Perphaps Microsoft
should have a mailbox in the net for this kind of things -- this
is much easier than going through the regular routes...). And,
perhaps this doesn't occur in MSC 5.0 or 5.1 any more...

--
-- Markku Savela,   msa@clinet.fi
-- (Note: I cannot send mail -- do not expect mail replys)

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Why NULL is 0

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1135
          for SXJVK@ALASKA; Sun, 13 Mar 88 06:01 AST
Received: by UWAVM (Mailer X1.25) id 7048; Sun, 13 Mar 88 07:01:00 PST
Date:         Sat, 12 Mar 88 19:07:25 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         "Stephen J. Friedl" <friedl@vsi.uucp>
Subject:      Re: Why NULL is 0
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <124@polygen.UUCP>, pablo@polygen.uucp (Pablo Halpern) writes:
> However, if I were writing a C compiler, I would choose a size for all
> pointers equal to the size of the largest possible pointer.  This would
> allow code that passed uncasted NULL to work correctly, provided NULL
> is a type as large as a pointer.  This is not because dpANS says it
> should be so, but because so much code would break if it were not.
> Perhaps ANSI should add the restriction that all pointer types must be
> the same size in an effort to "codify common existing practice."

I think this is naive.  Presumably, the large "common" pointer
format would pass around the machine OK but it still must be
converted to the machine's native pointer types to actually
use -- how efficiently will this be done?  This might be like the 80x86
huge pointer calculations or the old promote-float-to-double
rules -- they makes life a little easier for the (lazy?)
programmer at the larger expense in time and compiler complexity

Perhaps more reasonable is to promote all pointers to the same
large width while passing them on the stack and convert them back
on the other end: this would fix the alignment issues but would
still slow things down.

I don't favor this approach but I bring it up in the spirit of
this discussion.  The obvious answer is to be very rigorous about
casting your pointers and knowing when to do so.  This is a
bummer for the beginners but we all had to go through it unless
we develop on a VAX :-).
--
Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA   *Hi Mom*
CSNet: friedl%vsi.uucp@kent.edu  ARPA: friedl%vsi.uucp@uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: ANSI C & Fortran 8x - Expand cpp to partially support

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1162
          for SXJVK@ALASKA; Sun, 13 Mar 88 06:14 AST
Received: by UWAVM (Mailer X1.25) id 7065; Sun, 13 Mar 88 07:13:34 PST
Date:         Sat, 12 Mar 88 17:41:08 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Alan J Rosenthal <flaps@dgp.toronto.EDU>
Subject:      Re: ANSI C & Fortran 8x - Expand cpp to partially support
              generalized precision
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>


[In editing David Hough's article below, I have taken representative
 paragraphs.  -ajr]

In article <44981@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes:
>Comment #26, Section 3.8.8 and 2.2.4.2: predefine generalized precision macros
>...
>__int__(p) is evaluated to the name of the smallest signed int type
>that contains all the signed p-digit integers, i. e. the interval
>[-(10**p)+1,10**p-1].
>...

Useable but not very useful.  Also not sufficiently well defined.  What
is its value for p > log10(LONG_MAX)?  Also, your macros are very
different from all other preprocessing macros in that they don't simply
substitute to a string (with possible replacements from the arguments).
Also also, nowhere else does the preprocessor know about names of types.

>__INTEGER__(p) is evaluated to the Fortran name of the type corresponding
>to __int__(p), or to INTEGER if no Fortran compiler is supported.
>...

Since no Fortran compiler is supported by the ANSI C standard, you
can just say "INTEGER".  The C standard does not mandate a separate
preprocessor, nor should it.  That would be the domain of a
Preprocessor Standard.  It seems like that is what you are proposing.
Perhaps you should write one, or get someone else to write one.

ajr
--
If you had eternal life, would you be able to say all the integers?

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: Don't use Scanf()

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1172
          for SXJVK@ALASKA; Sun, 13 Mar 88 06:14 AST
Received: by UWAVM (Mailer X1.25) id 7080; Sun, 13 Mar 88 07:14:16 PST
Date:         Sun, 13 Mar 88 00:58:41 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Henry Spencer <henry@utzoo.uucp>
Subject:      Re: Don't use Scanf()
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

>     For example, if you want to print a string fast, you would write
> a routine that uses only putc...

!!NO!!  If you want to print a string fast, you use fputs and insist that
your supplier implements it properly.  Putc has to do things like buffer-
overflow checking on every character; a fast implementation of fputs can
inspect the buffer *once*, note that there is room for N more characters,
copy N characters at high speed, and then update counts and so forth *once*.
This is a major efficiency win over putc if you are doing it a lot.

Unfortunately, not all implementors make the effort to make stdio fast.
In general, System V stdios are fast and 4BSD ones are not.  (There are
exceptions to this, both ways, and I believe the 4BSD one is going to be
improved.)
--
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: volatiles/consts inside structs in dpANS C

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1209
          for SXJVK@ALASKA; Sun, 13 Mar 88 06:23 AST
Received: by UWAVM (Mailer X1.25) id 7098; Sun, 13 Mar 88 07:23:22 PST
Date:         Sun, 13 Mar 88 00:54:11 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Henry Spencer <henry@utzoo.uucp>
Subject:      Re: volatiles/consts inside structs in dpANS C
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

As I recall (my copy isn't handy), the latest draft says that const,
volatile, etc. inside a struct sort of pop to the surface when you attempt
something like an assignment.  So assigning to a struct with a const
member is illegal.  Personally, I think such "buried qualifiers" should
simply be illegal, since they are useless...
--
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)

Subject:  Re: syntactical convenience

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 1230
          for SXJVK@ALASKA; Sun, 13 Mar 88 06:29 AST
Received: by UWAVM (Mailer X1.25) id 7118; Sun, 13 Mar 88 07:29:11 PST
Date:         Sun, 13 Mar 88 00:55:15 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Henry Spencer <henry@utzoo.uucp>
Subject:      Re: syntactical convenience
Comments: To: info-c@BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK@ALASKA>

> A more important addition, and a surprising lack in the standard, is the
> preprocessor, which doesn't allow inserting preprocessing directives. Our
> standards rep had no good arguments against adding the capability, which is
> no harder to implement...

Not all implementors would agree.
--
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

schmidt@BONNIE.ICS.UCI.EDU (Douglas C. Schmidt) (03/14/88)

   Why doesn't someone do something about all the blasted "undelivered
   mail messages emanating from ALASKA.BIT?  This is cluttering up
   the bboard!
   
   dcs

qwerty@drutx.ATT.COM (Brian Jones) (03/14/88)

About 50% of the traffic at our site looks like the following message:

Also, a number of these are repeating, some multiple times.  Someone's
software is broken somewhere...

*In article <12345@brl-adm.ARPA>, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU writes:
* Subject:  Re: Header problems
* 
* [Non-Deliverable:  User does not exist or has never logged on]
* 
* Reply-To: Info-C@BRL.ARPA
* 
* Received: From UWAVM(MAILER) by ALASKA with Jnet id 9841
*           for SXJVK@ALASKA; Sat, 12 Mar 88 21:05 AST
* Received: by UWAVM (Mailer X1.25) id 6269; Sat, 12 Mar 88 22:04:47 PST
* Date:         Thu, 10 Mar 88 16:07:15 GMT
* Reply-To:     Info-C@BRL.ARPA
* Sender:       Info-C List <INFO-C@NDSUVM1>
* From:         SIEMON <mls@whutt.uucp>
* Subject:      Re: Header problems
* Comments: To: info-c@BRL-SMOKE.arpa
* To:           Vic Kapella <SXJVK@ALASKA>
* 
* In article <3416@chinet.UUCP>, dag@chinet.UUCP (Daniel A. Glasser) writes:

DELETED TEXT

* Michael Siemon
* contracted to AT&T Bell Laboratories
* (these are my opinions, not theirs)
* ihnp4!mhuxu!mls
-- 

Brian Jones  aka  {ihnp4,allegra}!{drutx}!qwerty  @  AT&T-IS, Denver

richardh@killer.UUCP (Richard Hargrove) (03/15/88)

---
I think we've punted ALASKA.

richardh
--------

twb@hoqax.UUCP (BEATTIE) (03/15/88)

What is all this "Undelivered mail" doing here?

djones@megatest.UUCP (Dave Jones) (03/16/88)

in article <12311@brl-adm.ARPA>, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU says:
> 
> Subject:  Re: Why NULL is 0
> 
> [Non-Deliverable:  User does not exist or has never logged on]
> 
> Reply-To: Info-C@BRL.ARPA
> 
> Received: From UWAVM(MAILER) by ALASKA with Jnet id 8001
>           for SXJVK@ALASKA; Sat, 12 Mar 88 10:50 AST
> Received: by UWAVM (Mailer X1.25) id 5338; Sat, 12 Mar 88 11:49:55 PST
> Date:         Fri, 11 Mar 88 21:56:46 GMT
> Reply-To:     Info-C@BRL.ARPA
> Sender:       Info-C List <INFO-C@NDSUVM1>
> From:         Doug Gwyn <gwyn@brl-smoke.arpa>
> Subject:      Re: Why NULL is 0
> Comments: To: info-c@brl-smoke.arpa
> To:           Vic Kapella <SXJVK@ALASKA>

...

>

I'm getting dozens and dozens of these returned-mail postings to
comp.lang.c.  They are all postings that have appeared under their
original headings.  Anybody know what's going on?


		Dave Jones
		Megatest Corp.
		880 Fox Lane
		San Jose, CA.
		95131

		(408) 437-9700 Ext 3227
		UUCP: ucbvax!sun!megatest!djones
		ARPA: megatest!djones@riacs.ARPA


Lines
to
make
this
posting
as
long
as
the
original,
so
the
mailer
will
accept
it.

be@dde.uucp (Bjorn Engsig) (03/16/88)

In a lot of articles, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU writes something
like:
> [Non-Deliverable:  User does not exist or has never logged on]
> Reply-To: Info-C@BRL.ARPA
> Received: From UWAVM(MAILER) by ALASKA with Jnet id 8323
>           for SXJVK@ALASKA; Sat, 12 Mar 88 11:30 AST
> To:           Vic Kapella <SXJVK@ALASKA>

Aren't there any better way to do this.  It's guite boring to 'n'
through all these 'undelivered mail's, and one might even miss something
of interest.
-- 
Bjorn Engsig, E-mail:  ..!uunet!mcvax!diku!dde!be  or  be@dde.uucp
--
Hofstadters Law: It always take longer than you expect, even if you take into
		 account Hofstadters Law.

rsalz@bbn.com (Rich Salz) (03/17/88)

Dave Jones, djones@megatest.UUCP (Dave Jones) asks why comp.lang.c is
getting filled up with messages like:
 > 
 > Subject:  Re: Why NULL is 0
 > 
 > [Non-Deliverable:  User does not exist or has never logged on]
 > 
 > Reply-To: Info-C@BRL.ARPA
 > 
 > Received: From UWAVM(MAILER) by ALASKA with Jnet id 8001
 >           for SXJVK@ALASKA; Sat, 12 Mar 88 10:50 AST
 > Received: by UWAVM (Mailer X1.25) id 5338; Sat, 12 Mar 88 11:49:55 PST
 > Date:         Fri, 11 Mar 88 21:56:46 GMT
 > Reply-To:     Info-C@BRL.ARPA
 > Sender:       Info-C List <INFO-C@NDSUVM1>
 > From:         Doug Gwyn <gwyn@brl-smoke.arpa>
 > Subject:      Re: Why NULL is 0
 > Comments: To: info-c@brl-smoke.arpa
 > To:           Vic Kapella <SXJVK@ALASKA>

The answer is that the comp.lang.c newsgroup is gatewayed into an
Internet mailing list, info-C.  One of the recipients is at BITNET
site.  And when BITNET mail has problems it tends to do, unh, things
that are anti-social to Usenet (if not the rest of the Internet
world :-).  The person in charge, a postmaster at one of the BITNET
sites, found out and shut things off within a day or two, but
that was still too late to prevent about 75 of these messages from
costing Usenet thousands of dollars to transmit.

Yet another argument against unmoderated bidirectional gateways.

The most interesting question, tho, still remains unanswered:  if the
user does not exist, or has never logged in, how did the subscribe
to the INFO-C mailing list?

Speculations, flames, and follow-ups should probably be sent to me.
At any rate, keep them out of the comp.lang.c newsgroup.
	/r$
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/23/88)

[Non-Deliverable:  User does not exist or has never logged on]

Received: From UOGUELPH(SOSLIZ) by ALASKA with Jnet id 7625
          for OP@ALASKA; Wed, 23 Mar 88 06:13 AST
Date: 23 March 1988, 10:01:43 EST
From: SOSLIZ   at UOGUELPH
To:   OP at ALASKA

Hi.   You don't know me, but because you're the operator, I'm hoping you
have access to the information I need.  Cathy Hirt is a friend of mine,
and I am trying to reach her boss, Kurt.  I don't know what his last
name is, all I know is that he works for the U. of A. Computer Center.
Do you know him, and more importantly, can you provide me with his
USERID (and node)?  Thanks in advance.
Elizabeth Reemeyer, Computing Services, University of Guelph.