HDTenEightyP/NetNews huggingface dataset:
From: gsf@ulysses.att.com (Glenn S. Fowler)
Subject: Re: Include file directory search path
Date: Sat, 21 Nov 1992 03:30:34 GMT
Organization: AT&T Bell Labs

In article <1992Nov19.171758.14067@eagercon.com> eager@eagercon.com writes:
>In article 92Nov18151448@mdtf14.fnal.gov, sim@mdtf14.fnal.gov (Jim Sim) writes:
>>Is there a way to force the C preprocessor to use the same search path to
>>locate nested include files (files included by another include file) 
>>that it uses to locate non-nested include files. My motivation for doing 
>>this is to allow developers to make "test" changes to nested include files 
>>that don't affect "official" versions of those include files.
>
>The compiler uses the same directory search path for all included files.

true if all includes are <...>
"..." include searching, however, is up to the compiler implementation
there are two popular "..." include search styles

1) K&R: first check the current directory, then the <...> directories,
   where the current directory is usually the directory of the top level
   source file
2) "Reiser" (the traditional standalone UNIX cpp): first check the directory
   of the including file, then the <...> directories

there is no standard "..." include style
ANSI C leaves it as implementation-defined

1 & 2 cause trouble in the case mentioned above -- for most C compilers
it is impossible to override a nested "..." include from a local dir

AT&T does a lot a viewpathing, so this situation is not acceptable
our local cpp accepts the option -I- that treats all includes as <...>
to avoid the problem -- note, however, that using -I- may require
additional -I dirs, e.g., for a "sys/foo.h" in -Ixxx that includes "sys/bar.h"
as "bar.h" (using 2 above), an additional -Ixxx/sys is required
our local make generates the -I options, so we avoid most of the
-I maintenance problems

GNU cc picked up -I- a few years back

Glenn Fowler    (908)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,ucbvax}!ulysses!gsf              internet: gsf@ulysses.att.com
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: converting unsigned int to signed int
Date: 20 Nov 92 18:11:36 GMT

In article <19226@ucdavis.ucdavis.edu>, fzjaffe@othello.ucdavis.edu (Rory Jaffe) writes:
> What is a safe, portable method of converting from signed int to
> unsigned?
> I want the most negative signed value to convert to 0, and the most
> positive signed value to (max signed int) + abs(max negative signed
> int).

In article <1992Nov20.104109.21538@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) replies:
> This may or may not be possible.  There is no guarantee that signed and
> unsigned ints have the same "range", the same number of distinct
> possible values.

That is correct.  Although there is a guarantee that they take up the
same amount of storage and have identical representations for the values
that are representable in both types, and most implementations do
provide the same range, it is not a guaranteed property.  Assuming that
unsigned int does have the same range, der Mouse goes on to give a
complex method for doing the conversion.  Because of the properties of
unsigned arithmetic, however, the complexity is unnecessary; all that is
required is to do the arithmetic in an unsigned type:

	ui = (unsigned)i - (unsigned)INT_MIN;
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
Apparently I was misinformed. -- Calvin
Newsgroups: comp.lang.c,comp.software-eng
From: leisner@wrc.xerox.com ( Marty Leisner)
Subject: Re: Will we keep ignoring this productivity issue?
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 16 Nov 1992 15:16:25 GMT

On the productivity issue, there was an excellent article on 
"A Software Process Immaturity Model" by Anthony Finkelstein in ACM Sigsoft, October.

The CMM model deals with:
initial (ad hoc/chaotic).
repeatable
defined
managed
optimising

But what about before initial?
There levels are:
0 foolish -- (negligent) failure to allow successful development process
-1 stupid -- (obstructive) counterproductive process imposed
-2 lunatic -- (contemptuous) disregard for good software engineering institutionalised.



--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Can you program in C?
Organization: Texas Instruments Inc
Date: Tue, 17 Nov 1992 22:41:20 GMT

In <00963BF4.675CEA80@vms.csd.mu.edu> 2644danticoj@vms.csd.mu.edu writes:

>So, can you help me write these programs, thereby
>allowing me to graduate and go on to serve my country as an officer on a
>nuclear submarine? Please???? My future depends on it. 

Have things changed THIS much since Admiral Rickover died?  

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
From: fahad@cs.pitt.edu (Fahad A Hoymany)
Newsgroups: comp.lang.c
Subject: 2-D Arrays, Revisited.
Date: 17 Nov 92 00:45:13 GMT
Organization: Univ. of Pittsburgh Computer Science

I asked about this before and I read the FAQ list but there was no answer.
I'll try to state the problem more clearly this time.

I am writing a function that should accept a 2-D array (hopefully of any
size), operate on that array, and returns 'anything' to the caller. Please
don't suggest I use double pointers because I do not want to restrict the 
users of my function to use them when they are used to declaring arrays
as : int a[2][5]. 

What should the formal parameters line look like?
From: 6500msd@ucsbuxa.ucsb.edu (Michael D'Errico)
Newsgroups: comp.lang.c
Subject: Re: Funny problem with a pause routine
Date: 19 Nov 92 01:49:12 GMT

In article <9232123.22703@mulga.cs.mu.OZ.AU> carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer) writes:

>ok, here's a routine I copied from a book, and can see no reason why
>it won't work, but first, some background ..

>[background deleted]

>void pause()
>{
>    char ans;
>    fflush(stdin);
>    fprintf(stdout, "Press <Return> to continue\n");
>    ans = getchar();
>    fflush(stdin);

>    return;
>}

>I've tried this with the getchar cast to void [ (void)getchar(); ],
>and tried gets(), getc() etc, all to no avail.

There are two things I don't like about this code (this is not a flame):
        1) pause() is a UNIX system function
           defined in <unistd.h> so you should
           refrain from using that name.

        2) getchar() returns an INT!!!  This is so
           that EOF can be returned -- it doesn't
           fit in a char.  This has repeatedly been
           discussed in this newsgroup since there
           is a tendancy to assume that a function
           called getchar() returns a char.  It is
           far worse when a book claims this.

I tried this code on my HP 9000 433s with cc and had no problems
with it even with the 'char ans;' declaration, so I don't know what
your problem could be...

Michael D'Errico
6500msd@ucsbuxa.ucsb.edu
From: eager@eagercon.com (Michael J. Eager)
Subject: Re: MSDOS C Compiler advice?
Reply-To: eager@eagercon.com
Organization: Eager Consulting
Date: Tue, 17 Nov 1992 07:05:19 GMT

In article 721891955@student.tc.umn.edu, forb0004@student.tc.umn.edu (Eric Forbis) writes:
>I'll be taking C this Winter quarter, and would welcome any comments about 
>commercially available C compilers. We'll have a compiler available via Unix 
>accounts, but I'd prefer to slap something on the hard drive of my 386, 
>where it will be there after the course ends. 
>
>Are the commercial products (Borland, MS) extremely complex, worthy of a 
>course of themselves to learn to use? Or do they have a better interface? 

All of the compilers are reasonably easy to use, including Borland & MS.
No course is needed to use the compiler, just a bit of reading the manual.

>
>I noticed that MS C users can upgrade to the SDK for a mere $139; extremely 
>tempting for a cash-strapped married student. However, I've heard that the 
>SDK is a time- consuming pain to learn. I haven't heard much about Borland's 
>frameworks, and assume you've got to dish out the $400; no upgrade. I won't 
>be doing any Windows programming for some time to come, of course, but 
>would like to look ahead a bit to avoid rebuying the wheel.

The SDK and Borland Framework are both for Windows programming.  SDK is complex
and detailed.  Neither is something that a brand new C programmer should 
purchase just to have.  If you buy it now, chances are that you will end up
buying an upgrade by the time you have enough experience with C to use either.

>
>The only difference I'm aware of is that Borland is said to compile a little 
>faster and sparely. I'm won't have a lot of time to spend on the compiler 
>itself, so any pretty point and run features would be welcome. 

If you can't program in C yet, compilation speed is not important :-).

Any, absolutely any compiler will be adequately fast for a course in C programming.
Time spent in compilation will not be significant in learning C, and usually
is not significant until you are working on files with hundreds or thousands
of lines of code, or compiling a significant number of files at a time.

Think of it this way, if compiler A compiles your program in seven seconds, 
how much more productive will you be if compiler B compiles it in five?

>
>BTW, is it true that there's no direct way to read and write disk volume 
>labels in C? How do you get around this; is assembly required?

No it is not true.  Look in the library manual for BIOS calls which will
read disk records.


---
Michael J. Eager		Michael.Eager@eagercon.com
Eager Consulting		(415) 325-8077 
1960 Park Boulevard, Palo Alto, CA 94306-1141
From: forb0004@student.tc.umn.edu (Eric Forbis)
Newsgroups: comp.lang.c
Subject: MSDOS C Compiler advice?
Date: 16 Nov 92 05:32:35 GMT
Organization: University of Minnesota

I'll be taking C this Winter quarter, and would welcome any comments about 
commercially available C compilers. We'll have a compiler available via Unix 
accounts, but I'd prefer to slap something on the hard drive of my 386, 
where it will be there after the course ends. 

Are the commercial products (Borland, MS) extremely complex, worthy of a 
course of themselves to learn to use? Or do they have a better interface? 

I noticed that MS C users can upgrade to the SDK for a mere $139; extremely 
tempting for a cash-strapped married student. However, I've heard that the 
SDK is a time- consuming pain to learn. I haven't heard much about Borland's 
frameworks, and assume you've got to dish out the $400; no upgrade. I won't 
be doing any Windows programming for some time to come, of course, but 
would like to look ahead a bit to avoid rebuying the wheel.

The only difference I'm aware of is that Borland is said to compile a little 
faster and sparely. I'm won't have a lot of time to spend on the compiler 
itself, so any pretty point and run features would be welcome. 

BTW, is it true that there's no direct way to read and write disk volume 
labels in C? How do you get around this; is assembly required?

Thanks much,
---------

Eric Forbis      forb0004@student.tc.umn.edu
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Multiple &'s in an if statement
Keywords: &
Organization: Sequoia Peripherals, Inc.
Distribution: comp.lang.c
Date: Mon, 23 Nov 92 18:09:04 GMT

In article <1992Nov23.164530.19214@iacd> bcochell@ips.iacd.honeywell.com writes:
>Greetings,
>
>Can anyone explain why this works correctly (That is, it checks to see that
>the last 5 characters of name are all digits and that it is null terminated):
>
>   if ( isdigit(name[strlen(path)]) &
>        isdigit(name[(strlen(path) + 1)]) &
>        isdigit(name[(strlen(path) + 2)]) &
>        isdigit(name[(strlen(path) + 3)]) &
>        isdigit(name[(strlen(path) + 4)]) )
>      if ( iscntrl(name[(strlen(path) + 5)]) ) {
>         printf("%s\n",name);
>      }
>
>While the following does not?:
>
>   if ( isdigit(name[strlen(path)]) &
>        isdigit(name[(strlen(path) + 1)]) &
>        isdigit(name[(strlen(path) + 2)]) &
>        isdigit(name[(strlen(path) + 3)]) &
>        isdigit(name[(strlen(path) + 4)]) &
>        (name[(strlen(path) + 5)] == NULL ) ) {
>      printf("%s\n",name);
>   }

Because you are using '&' (bitwise and), not '&&' (boolean and) and 
isdigit has some value other than 0 or 1. The functions declared
in <ctype.h>, isdigit, islower, etc. are guaranteed to return some
non-zero value if the character in question staisfies the condition;
they are *not* guaranteed to return 1.

So suppose isdigit returns 4 if the character being tested is a 
digit. And suppose that name[strlen (path) + 5] works and returns
1. (It need not work because NULL can be defined as (void *) 0. Even
if it works it is bad programming practice to use NULL in this
context where it is not a pointer).

Then the method that does not work comes down to evaluating

   4 & 4 & 4 & 4 & 4 & 1

which indeed is equal to 0 because 1 and 4 have no nonzero bits
in common.

Change your example to:

   if ( isdigit(name[strlen(path)]) &&
        isdigit(name[(strlen(path) + 1)]) &&
        isdigit(name[(strlen(path) + 2)]) &&
        isdigit(name[(strlen(path) + 3)]) &&
        isdigit(name[(strlen(path) + 4)]) &&
        (name[(strlen(path) + 5)] == '\0' ) ) {
      printf("%s\n",name);
   }

or even better, something that doesn't recompute strlen (path) 6 times.


-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
Newsgroups: comp.lang.c,comp.software-eng
From: pjh@mccc.edu (Pete Holsberg)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: The College On The Other Side Of Route One
Date: Thu, 19 Nov 1992 23:24:08 GMT

In article <books.110.0@fsunuc.physics.fsu.edu> books@fsunuc.physics.fsu.edu (Roger Books) writes:
=In article <1992Nov17.091220.9284@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
=>
=>IMHO, there is probably no better background for SE than physics.  Why? 
=>Problem solving.  Experimental techniques.  Basic understanding of the
=>strangeness of the universe.  All useful.  
=
=I don't know about that last one.  The Physicists are some of the most
=intelligent people I know.  They can solve almost any problem you throw
=at them, but, their programming is kludgey and atrocious to maintain.

Then how about English majors? Writing is writing.
From: igor@pccentre.msk.su (Igor Kudashev)
Newsgroups: comp.lang.c
Subject: Please, send me FAQ.
Date: 16 Nov 92 06:30:16 GMT
Reply-To: igor@pccentre.msk.su
Organization: AviaExport
X-Newsreader: TIN [version 1.1 PL6]

Please, send me FAQ.

Thanks in advance.
Igor V. Kudashev
E-mail: igor@pccentre.msk.su
From: dsbb@ns1.cc.lehigh.edu (D. SPENCER BEECHER)
Newsgroups: comp.lang.c
Subject: Re: Please Help Me Keep My Job!
Date: 20 Nov 92 01:27:16 GMT
Organization: Lehigh University

hollasch@kpc.com (Steve Hollasch) writes:
>    My manager has asked me to finish several projects by the end of this
>year, and they're really hard!  I told her I could do them, but now I don't
>know; they're pretty tricky.  I'm sure other people have done stuff like
>this, so why should I reinvent the wheel?  Why not use the resources of the
>net?
   (blah, blah, blah)


HEY EVERYBODY!! I have this great idea.  I'll go out and get a job
programming.  If each of you would be so kind as to write five or
six lines of code for each project I get into, I'll never have to
work or learn or do anything.  What a plan.  Actually, its not like
I'd be asking any of you to do anything you haven't done before...
   (blah, blah, blah)
-- 
                   _ _     _ _     _ _
  -Spence         [O.O]   )x.x(   )O.O(
                    O       O      -*-
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: strange things with gcc
Date: 16 Nov 92 19:01:17 GMT
Organization: University of Helsinki

carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer) writes:
>I've ahd some funny problems with gcc on SunOS 4.1.2 of late, it doesn't
>seem to handle fflush(stdin) very well (ie not at all).
>
>either that, or I'm not using it correctly ?

You're not using it correctly, fflush(stdin) is not required to do
anything useful, and has no clear meaning.  See the FAQ, question
11.5.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
From: rpeck@pure.com (Ray Peck)
Subject: Re: Typedefing builtin... thanks.
Organization: Pure Software, Los Altos, CA
Date: Tue, 17 Nov 1992 23:55:19 GMT


In article <1992Nov9.150414.10221@odin.diku.dk> . . .:

>People generally tended to agree with me on the use of the names BYTE, WORD,
>and LWORD to represent unsigned 8, 16, and 32 bit variables in my simulation

>The major arguments used to justify these techniques were about portability.
>A program is easier to port, when you can change some typedefs in a header
>file, instead of changing a lot of ints to longs all over the code.

The only problem with this is a WORD is not a portable concept (i.e.,
people in 68k's call 16 bits a word, while people on Real Machines ;-)
call 32 bits a word.  All modern machines use 32b and up.


For this reason, I prefer types int8, int16, int32, or (better) u1b,
u2b, u4b, (unsigned) and s1b, s2b, s4b (signed).

-- 
Ray Peck						rpeck@pure.com
Pure Software						415-903-5100

Xref: sparky comp.lang.c:16878 comp.software-eng:4431
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 20 Nov 92 10:47:09 EST

In article <By0G8A.1M5@cs.uiuc.edu>, johnson@cs.uiuc.edu (Ralph Johnson) writes:
> kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
> In response to a probably too long article on my part:
>>We are in the world of wild conjecture and the
>>nature vs. nuture issue could go on forever.  We need to speak of data here.
> Although there were probably many things wrong with my article, it was not
> wild conjecture, and I was pointing to data.  The claim was made that,
> like everything else, excellence in programming was something you either
> had or didn't have, and trying to train someone to be a top programmer
> was a mistake.  My point was that claim was completely rediculous.
May have misread.  Agree that we can and should try.  Based on my experience,
we are not successful yet.
> It is true that there are very large differences in the skills of 
> programmers.  It is also true that our theories of how to manage software
> do not take account of this, and it should.  
Disagree.  See Boehm, DeMarco, Weinberg for discussions.
>  Most differences are acquired,
I am still not sure about the supporting evidence for this claim.
[...]
  However, I think
> that it is *possible* to come up with an effective theory of how to teach
> software development, and that, given enough effort, we will eventually
> do so.
When I was in graduate school eons ago, this same question was being asked then
of well known disciplines, and the answer at that time, that there was no
standard theory (note: maybe somewhat different question - the issue IMHO is
how we teach something to provide the most measurable difference in the skill
level of the people using the discipline after as compared to before the
teaching.)

Thanks for the ref  - will try to get.

George Kambic
sd
                             
Newsgroups: comp.lang.c
From: ronnie@lysator.liu.se (Ronnie Sahlberg)
Subject: Re: What is meant by: double A[n,m]?
Organization: Lysator Academic Computer Society, Linkoping University, Sweden
Date: Wed, 18 Nov 1992 21:37:17 GMT

torstein@itekiris.kjemi.unit.no (torstein hansen) writes:

>As a newcomer to C, previously programming in Pascal, I used the
>following declaration in one of my programs:

>double A[n,m];

>I assumed (erronously) that this would give a n by m matrix. But
>obviously, it didn't.  But the compiler never gave any errors or
>warnings, and using 

The compiler didnt flag any errors since there is nothing syntacticaly wrong
with the statement.
The comma-operator is used to string several expressions together into one 
expression. The comma-operator has a defined order of evaluation (as && and || also have) from left to right and the value of the resulting expression is the
right operand of the comma-operator.
Thus when writing   A[n,m]  it will perform like :
1,  Evaluate n and throw this value away.
2,  Evaluate m and use this value to index array A.

>  A[rownumber,colnumber]=some_value;
> 
>was also accepted by the compiler.  I'm not asking for the correct 
>way to define an array, I found that out quickly, but what is meant 
>by A[n,m]?  It seems like the compiler just ignores the n and makes 
>it A[m].  This is also the case when assigning values to the array.

when writing double A[n,m] you get access to the same element as if you had 
written double A[m].
You can even write something like A[printf("Hello World\n"),m]; and it will
 also be a valid C expression, although it might look quite weird.

>That is:
>  double A[2,2];  
>gave same result as 
>  double A[2];

>  A[0,1] = some_value;
>gave same result as
>  A[1,1] = some_value;
>and 
>  A[1] = some_value;

>Can somebody enlighten me in this matter?  I couldn't find anything
>about it in any of the C books I have.  If double A[n,m] is illegal,
>shouldn't I get a warning at least?

>Has it something to do with the comma operator, discarding the first
>value inside the braces?

>By the way, the compiler I used was Turbo C++ ver. 3.1, just in case
>this behaviour isn't standard.

It is standard behaviour.

>Torstein Hansen
>torstein@itekiris.kjemi.unit.no
>--
>Torstein Hansen
>torstein@itekiris.kjemi.unit.no



ronnie sahlberg      ronnie@lysator.liu.se
Xref: sparky comp.lang.c:16713 comp.software-eng:4368