HDTenEightyP/NetNews huggingface dataset:
From: freeman@gradient.cis.upenn.edu (Jon Freeman)
Newsgroups: comp.lang.c
Subject: Opinions about Purify
Date: 11 Sep 92 01:31:06 GMT
Organization: University of Pennsylvania

I would like to know what the people on this newsgroup think about
Purify, a product for finding run-time memory errors in C (and C++)
programs.  I attended a C++ seminar taught by Lippman, the author of
_C++ Primer_, and he said it was invaluable when he and his colleagues
were writing the AT&T C++ compiler--a pretty strong endorsement, I'd
say.  Purify seems a bit expensive to me--do other people think it's
really worth the money?  (I don't know if it's considered appropriate
to state exactly how much it costs, so I won't.)  Are there any other
programs out there with similar functionality that cost, say, no more
than $1000 for a single-CPU license?

				Thanks,
				 Jon
-------------------------------------------------------------------------------
"Before leaving your car, turn off     |   Jon Freeman
the engine and remove the key."        |   freeman@gradient.cis.upenn.edu
--Pennsylvania Driver's Guide, p. 38   |   Office: (215) 898-4612
Xref: sparky comp.lang.c:13549 comp.lang.c++:13547
From: jeff@BofA.COM (Jeff Tate)
Newsgroups: comp.lang.c,comp.lang.c++,comp.sun.misc
Subject: Debugger - PLEEZZZZZZ
Date: 11 Sep 92 19:10:51 GMT
Distribution: usa
Organization: Bank of America, Capital Products, RMTG #5906

We are using Sun's Ansi C compiler - you know, the one that hides inside the
C++ translator and turns into K&R deformed monster speak.

Well, is ok - but ....    dbxtool SUX SUX SUX SUX

Apart from the UI which is OLD and BAD and SLOW, it does not handle function
names longer than 3 characters (well ok, 15).

PLEEZ, PLEEZ, PLEEZ tell me which debugger I should be using.  Money ought to
be no object but, well, you know, so prices too please.

I will summarise if anybody is kind enough to help

Thanx
-- 

  +------------------------------------------------------------------+
  +  Jeff Tate                            Voice:  (415) 622 0890     +
  +  Manager, RMP Systems                 Fax:    (415) 622 2892     +
  +  Bank of America #5906                                           +
  +  San Francisco, CA 94104              e-mail: uunet!odinba!jeff  +
  +                                               jeff@BofA.COM      +
  +------------------------------------------------------------------+
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Optimizers and (NaN != NaN) (was Re: How i
Organization: TauMetric Corporation
Date: Tue, 15 Sep 1992 16:52:24 GMT

cflatter@nrao.edu (Chris Flatters) writes:

>In article 25805@kronos.arc.nasa.gov, raymond@kronos.arc.nasa.gov (Eric A. Raymond) writes:
>>>including a NaN itself. So `if (x != x) printf("A NaN\n");' could do
>>
>>I tried this in one compiler and it didn't work.  It is possible that
>>the compiler optimized the test away.  Is there any way to eliminate
>>the optimization via a source hack?

>Your compiler/hardware combination does not comply with IEEE-754.  File
>a bug report (or buy a better compiler).

After a careful re-reading of 754, I'm not convinced it requires that
(x!=x) hold for NaN's.  NaN's must not compare equal, but that is not
the same as saying they must compare unequal!

IEEE-754 talks about "equal", "unequal", and "unordered".  NaN's
are "unordered", and it is unspecified (in 754 or the C Standard)
whether the != operator in C includes "unordered".

It seems to me, then, that the C expression (x!=x) could be either
true or false for a NaN and still conform to 754.  It is clear,
however, that (x==x) must be false for NaN's.  (I wonder how
many compilers get that right.)

IEEE-754 recommends that certain functions be provided to test for
NaN's and other special cases.  An implementation which claims 754
conformance really should provide them (and many do).  Check your
manual for a function with a name like "isnan".  That should be the
most reliable way to test for a NaN.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: interpreting stbuf.st_ctime...
Organization: Interactive Systems, Cambridge, MA 02138-5302
Distribution: comp.lang.c
Date: Fri, 11 Sep 1992 23:11:56 GMT

In article <JOHNY.92Sep11132923@nexus.yorku.ca> johny@nexus.yorku.ca (John Saroglou) writes:
>Does anyone out there know how to interpret or convert to readable format
>output generated by the following peice of c code:
>	char *fname="x.c";
>	stat(fname,&stbuf);
>	printf("%d\n",stbuf.st_ctime);

	#include <time.h>
	printf("%s", ctime(&stbuf.st_ctime));
	/* or %.24s if you want to suppress the automatic newline */

>As you've noticed i'm trying to obtain the creation time of x.c.

On Unix systems, st_ctime is the last time the file's properties were
modified.  The creation time is not available.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Xref: sparky comp.lang.c:13708 sci.math:11522 comp.lang.misc:3092 comp.lang.fortran:3578 comp.std.c:2635
From: dsb@duke.cs.duke.edu (D. Scott Bigham)
Newsgroups: comp.lang.c,sci.math,comp.lang.misc,comp.lang.fortran,comp.std.c
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 15 Sep 92 22:57:04 GMT
Followup-To: comp.lang.c
Organization: n. Arrangement in an orderly or logical fashion.  See "miracle".

From the Holy Book of <1992Sep15.043224.27920@nntpd.lkg.dec.com>
  as spake by diamond@jit.dec.com (Norman Diamond) :

>In article <1992Sep12.164915.10734@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>>a_rubin@dsg4.dse.beckman.com (Arthur Rubin) writes:

>>>>>>	int a, b;   long c;
>>>My interpretation (from reading K&R 2) would be that c = a * b should be
>>>equivalent to c = (int)(a * b).

>Mr. Rubin,

Well, I'm not he, but your comments made me curious.

>           please state which section of the standard requires this.
>If you cannot, then please at least quote the text in K&R 2 that led you to
>this interpretation, so that we can see if K&R 2 has a bug that would be
>worth recommending for correction and/or warning about.

Section A7.6, "Multiplicative Operators", states that "The usual
arithmetic conversions are performed on the operands, and predict the
type of the result."  Since a and b are both int's, the arithmetic
conversions (described in section A6.5) predict that (a * b) should be as
well.

>>Indeed it is, but if that cast-to-int were to overflow you would get undefined
>>behaviour on that account.

>No, cast-to-int does not overflow.  It has a defined result.

Careful, this is _signed_ int we're talking about here.  According to
section A6.2, "Integral Conversions", "When any integer is converted to
a signed type, the value is unchanged if it can be represented in the
new type and is implementation-defined otherwise."

						-sbigham
-- 
Scott Bigham                   | The opinions expressed above are
dsb@romeo.cs.duke.edu          | (c) 1992 Hacker Ltd. and cannot be
bigham@hercules.acpub.duke.edu | copied or distributed without a
    (but not for long)         | Darn Good Reason(tm).
Xref: sparky comp.lang.c:13558 comp.sources.d:1266 misc.misc:3291 alt.sources:2054 comp.unix.wizards:3896
From: david@talgras.UUCP (David Hoopes)
Newsgroups: comp.lang.c,comp.sources.d,misc.misc,alt.sources,comp.unix.wizards
Subject: Re: 1992 International Obfuscated C Code Contest winners
Date: 11 Sep 92 12:42:15 GMT
Reply-To: david@talgras.UUCP (David Hoopes)
Followup-To: comp.lang.c
Organization: Tallgrass Technologies Inc.

In article <1992Sep10.135002.25527@wraxall.inmos.co.uk> nathan@elberton (Nathan Sidwell) writes:
>Landon C. Noll (chongo@hoptoad.uucp) wrote:
>: [the shar files]
>
>As chongo stated, my entry can't be posted from the USA. So
>I'm posting it from the UK, replace the shar'ed nathan.c with this code.
>

Why couldn't your program be posted from the U.S?






-- 
---------------------------------------------------------------------
David Hoopes                              Tallgrass Technologies Inc. 
david@tallgrass.COM                       11100 W 82nd St.          
Voice: (913) 492-6002 x323                Lenexa, Ks  66214        
Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: typedef and memory allocation
Organization: Computer Science, University of Melbourne, Australia
Distribution: usa
Date: Fri, 11 Sep 1992 13:04:28 GMT

winfree@math.arizona.edu (Art Winfree) writes:

>typedef double vector[3]

There should be a semicolon at the end of the above typedef.

>main()
>{
>.
>.
>.
>}
>
>funky_func()
>{
>vector bigarray[100];
>.
>.
>.
>}
>
>Question: Shouldn't a reasonable C compiler allocate enough
>(3*100*sizeof(double)) memory for bigarray for use when funky_func()
>is called? Evidently mine doesn't, since the code core dumps unless I
>explicitly calloc in funky_func().

Either your compiler is broken, or there is a bug somewhere else in your code.
(ie. in the elided part).

The only other possibility I can think of is that you might just possibly
be getting a stack overflow, but that seems highly unlikely.

>I know typedef itself doesn't
>cause any allocation, but are typedef'd types, as above, supposed to
>be sizeof'd and variables invoking them given appropriate memory, even
>if included in local function array definitions?

Yes, they are.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: mjn@pseudo.uucp (Murray Nesbitt)
Newsgroups: comp.lang.c
Subject: Re: argv in main
Date: 14 Sep 92 17:34:36 GMT
Organization: Private system in Toronto, ON


ghe@ruhets.rutgers.edu (Guangliang He) writes:

>According to the "C: A Reference Manual" (2nd Edition, by Harbison &
>Steele), the argument argv[argc] of main(argc, argv) may be a null
>pointer, but is not so in allimplementations. How safe is it to assume
>argv[argc] == NULL ? Should I be cautious about this?

The ANSI C Standard requires that argv[argc] be a null pointer.

In my experience, most pre-ANSI implementations also do this.

-- 
Murray
Newsgroups: comp.lang.c,comp.lang.c++,comp.os.msdos.apps,comp.os.msdos.programmer
From: kkt@philabs.philips.com (Kim-Kiat Tan)
Subject: Re: Should I buy BC++ 3.1??
Organization: Philips Laboratories, Briarcliff, New York
Date: Mon, 14 Sep 1992 23:27:22 GMT

>My suggestion:  Forget DOS.  GUI-based operating systems are the future
>in this business.  As soon as Windows NT and OS/2 are established, only
>a few die-hards will still be running DOS.  Let the people with old
>8088's have it.
>
	For personal use, I don't care much about window NT, mainly because
it require a lot of $$ to get into, starting from getting a new version of
stacker (if it exist), and what ever window programs that don't run right.

Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Sets in C
Organization: TauMetric Corporation
Date: Fri, 11 Sep 1992 16:58:38 GMT

kjb@cgl.citri.edu.au (Kendall Bennett) writes:

|s913578@yallara.cs.rmit.OZ.AU (Fantom) writes:

|>I've been looking at implementing sets in C,
|>the method needs to be able to handle sets of more than 32 elements
|>so using bit fields won't work

|Why not? Who says that a bitfield has to be 32 bits - make it as big as
|you want.

The C Standard allows an implementation to restrict the size of
bitfields to the size of an int.  A conforming program cannot
declare a bitfield larger than an int.  (Systems with 16-bit ints
often have an extension to allow 32-bit bitfields.)

I don't know of any compiler which allows arbitrarily large bit fields.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c
From: john@chance.gts.org (John R MacMillan)
Subject: Re: typedef and memory allocation
Organization: Reverse - esreveR :noitazinagrO
Distribution: usa
Date: Mon, 14 Sep 1992 11:52:50 GMT

|...  The
|call to calloc is probably the way to go.

One caution about this: if you were using calloc() to try to ensure
the doubles were all initially 0.0 you're making a non-portable
assumption.  It's better to explicitly assign 0.0 to all the elements.
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Help! what's wrong with this program?
Date: Sat, 12 Sep 1992 16:13:47 GMT
Distribution: usa
Organization: D'Arcy Cain Consulting

swalter@nyx.cs.du.edu (DreamWeaver) writes:
>Correct me if I'm wrong (lord knows that will happen ;) ... but doesn't
>   *bp++ = c;
>in the pusch() function actually mean (as far as order of precedence):
>   (*bp)++ = c;

The indirection operator and the increment operator have the same
precedence but associate right to left.  This means that this
expression is equivalent to "*(bp++)" exactly as one would expect.
What happened when you tried this on your compiler before posting?

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
Newsgroups: comp.lang.c
From: umward10@ccu.umanitoba.ca (Derek Ward)
Subject: Official FTP site for this newsgroup?
Organization: University of Manitoba, Winnipeg, Canada
Date: Wed, 9 Sep 1992 20:09:49 GMT


  I guess the subject pretty well sums it up.  Is there an official FTP
site for this group?  If so, which one?

Please reply via mail.  Thanks.

Derek

-- 
__   ///         University of Manitoba, Winnipeg,
\\\ ///          CANADA!      
 \XX//  AMIGA!   umward10@ccu.umanitoba.ca
Newsgroups: comp.lang.c
From: hansm@cs.kun.nl (Hans Mulder)
Subject: I disagree with lint(1)
Summary: Lint(1) says this is wrong.  Is it?
Keywords: lint, classic C
Organization: University of Nijmegen, The Netherlands
Date: Mon, 7 Sep 1992 08:34:01 GMT

Hello C gurus,

I just asked lint(1)'s opinion on this piece of code:

typedef struct foo *bar;

fun(b)
bar b;
{
    b=b;
}

struct foo
{
    int i;
}   the_struct;

main()
{
    fun(&the_struct);
    return 0;
}

Lint(1) says:

fun, arg. 1 used inconsistently	foo.c(5)  ::  foo.c(16)

I disagree.  The first argument to fun is a pointer to struct foo on both
lines.  In my book, that's the same.

What do you all think?

In case the answers for Standard C and Classic C are different, I'm
interested in the answer for Classic C.

--
Hans Mulder			hansm@cs.kun.nl
Xref: sparky comp.lang.c:13352 comp.sources.d:1251 comp.unix.wizards:3851 alt.sources:2021 misc.misc:3276
From: raymond@kronos.arc.nasa.gov (Eric A. Raymond)
Subject: Optimizers and (NaN != NaN) (was Re: How is NaN recognized?)
Organization: NASA/ARC Information Sciences Division
Date: Sun, 13 Sep 1992 23:36:29 GMT

>including a NaN itself. So `if (x != x) printf("A NaN\n");' could do

I tried this in one compiler and it didn't work.  It is possible that
the compiler optimized the test away.  Is there any way to eliminate
the optimization via a source hack?
Newsgroups: comp.lang.c
From: wittesa@reks.uia.ac.be (Willy Wittesaele)
Subject: Re: Help!!!  Please Read this message!?!?!?!?!...
Organization: U.I.A.
X-Newsreader: Tin 1.1 PL5
Date: Tue, 8 Sep 1992 11:04:34 GMT

Hello ,

better declare the type of your variables :

int apples ;
float oranges ;

apples=4 ;
oranges=4.0 ;

printf(....) ;



Willy

wittesa@reks.uia.ac.be
Newsgroups: comp.lang.c
From: baker-j@news.cis.ohio-state.edu (john t baker)
Subject: MS C/C++ V7, and the Heap
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 7 Sep 1992 08:39:51 GMT


Please let me know if there is a more specific place for this to go:

Has anyone had any experience with the new Microsoft C/C++ Version 7.0
giving them error C1060:compiler is out of far heap space?

The error occurs even when compiling a "hello world" program, and the only
TSR's I have running are the ones loaded by default by the 386MAX package
- which comes with Version 7 and without which the compiler will not work
at all.

Any help will be appreciated.
--
John Baker
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Only C gurus allowed?!?!
Date: 14 Sep 92 21:13:26 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Sep10.011058.1620@nb.rockwell.com>, wade@nb (Wade Guthrie) writes:
>Several people have said something to the effect of "If you don't REALLY know,
>don't answer".  Well, if one thinks he knows, then he really should reply --

I'd put that more like:

  if( you want to post a reply )
    if( you are certain of the answer (99 3/4%) )
      post solution
    else if( you're not sure, but you know where to find out for sure )
      look up solution
      post solution (or post where to find solution)
    else
      sit down & shut up.

>that's what the net community is all about.

The net should be about sharing knowlege, not what you "think" you know
(particularly when the right answer is well known).

>Come out of the tower and chill a bit.

That could apply to both sides.  You are eventually going to post something
that's wrong, and that's gonna get you posts & e-mail correcting you.  You
can't be so thin-skinned that one e-mail calling you a lame-brain is gonna
send you packing, or starting a thread complaining about how comp.lang.c
is a member's-only club.

-- 
You unlock this door with the key of imagination.  Beyond it is another
dimension: a dimension of sound, a dimension of sight, a dimension of mind.
You're moving into a land of both shadow and substance, of things and ideas.
You've just crossed over into... the Twilight Zone.
Xref: sparky comp.lang.c:13545 comp.lang.pascal:5336 comp.lang.misc:3028
From: art@world.std.com (Al Thompson)
Newsgroups: comp.lang.c,comp.lang.pascal,comp.lang.misc
Subject: Re: Opinions on case sensitivity in programming languages?
Date: 11 Sep 92 18:08:36 GMT
	<10SEP199215533727@envmsa.eas.asu.edu>
Organization: The World Public Access UNIX, Brookline, MA

In article <10SEP199215533727@envmsa.eas.asu.edu> ptran@envmsa.eas.asu.edu (Phi-Long Tran) writes:

   In article <ART.92Sep10132321@world.std.com>, 
   art@world.std.com (Al Thompson) writes...

   > In article <1992Sep10.034246.14218@oucsace.cs.ohiou.edu>
   > tswingle@oucsace.cs.ohiou.edu (Tom Swingle) writes:

   >> ...  1.  Do you prefer programming in a language which is case-sensitive
   >> or case- insensitive (or does it even make a difference to you), and
   >> why?

   > Case insensitive all the way.  A cat is the same animal as a cAt.

	Case sensitivity is a useful feature.  One usage is to name #define'd
   constants and macros using only uppercase characters.  This capitalization
   serves to tell the reader that "this identifier will be replaced; be
   careful."  Case sensitivity provides one more mechanism for encoding some
   more meaning into an identifier's name.  Some programmers use case to
   distinguish between functions and variables, as in Hungarian notation
   (e.g., capitalize the first letter in a function name).

But you can achieve this without case sensitivity in the language.  This
is a matter of style, it's not a matter of language design.

   >> ...  2.  How significant an issue is case-sensitivity in your preference
   >> toward one language over another?

   > Not very, but I still think case insensitivity the proper way because of
   > its correspondence to natural languages.  Another is an issue of
   > correctness.  For example if I have two variable k and K a simple typo
   > can turn my program into a pumpkin and the compiler won't say a word.

	I'm not sure that case insensitivity has a correspondence to natural
   languages.  It may with "spoken" language, where we stress intonation, etc.
   As for the written language, we take great care to distinguish a proper
   noun, an acronym, etc. using distinct cases.  As for program correctness,
   an undisciplined programmer may choose to change case depending on whether
   he/she feels like tapping the shift key, resulting in inconsistencies in
   the "form" and therefore, the readability of the code.  Likewise, I wonder
   if "k" and "K" are good identifiers at all?

Well, I didn't k and K as suggestions for good identifier choices I
picked them because they were short and illustrated the point.

In natural language, spoken or otherwise, case doesn't change the meaning
of a word.  I am only aware of two such words in the English language,
polish and Polish and job and Job.  (There's supposed to be a third but
which it is escapes me at the moment.  Does anybody know?)
Newsgroups: comp.lang.c
From: lappala@cse.unl.edu (Kristopher Lappala)
Subject: Large Memory Model ????
Summary: Problems with Large Memory Model
Keywords: Large Memory Model
Organization: University of Nebraska - Lincoln
Distribution: global
Date: Mon, 14 Sep 1992 01:01:32 GMT

I am writing a C program that will sample analog data via an A/D
card I have built.  I need to allocate between 500k and 1M of memory
for storage.  I have tried using malloc() with the large memory
model but this locks up my system when I try and fopen a file.
Is there another way to allocate LARGE amounts of memory using
Borland Turbo C/C++ ???  Is there a problem using fopen() in
the large memory model ?
	Thank you in advance for any suggestions

				K. Lappala
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: free() problem ...
Date: 9 Sep 92 16:13:15 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <79398@ut-emx.uucp>, wangyu@ccwf (Yu Wang) writes:
>I got a question on free().  It looks to me that free() doesn't
>actually make freed memory spaces available to other programs.

There's no guarantee that it will.  What free actually does with the
memory you send it is an implementation issue.

[description of program deleted]

>I ran the second program many times during a long period of time, but
>the available memory size I got from it was always 10MB less than the
>number I got from running the second program prior to the first
>program, i.e. 10 MB memory was never made available to other programs!

I expect that this is a `quality of implementation' issue.  If you have the
program hang on to all allocated memory until termination, the obvious
disadvantage is that no other program can use that memory.  On the other hand,
there may be systems where removing blocks of memory to a process' memory
space may be very expensive, and so the library writers proceeded on the
assumption that most programs don't allocate significantly large chunks of
memory (and also hang around for a long time), so it would be (mostly) ok
for them to hang on to what they have until termination.

-- 
Caught an internal error--.brainrc restored
Newsgroups: comp.lang.c
From: eng20009@nusunix3.nus.sg (TAN GIM WEE)
Subject: Re: Help! what's wrong with this program?
Organization: National University of Singapore
Distribution: usa
Date: Tue, 8 Sep 1992 13:09:07 GMT

Hello there, this is regarding the *bp++ expression.
I read in a book that for such an expression, the evaluation goes like
this:
the compiler increments bp, but due to the post-increment, the
expression will return *bp and assign the value of 'c' to the location
pointed to by 'bp' before the increment.

Can someone please enlighten me on the correctness of this. Thanks.

---------------------------------------------------------
Tan Gim Wee
EE Dept, NUS
internet: eng20009@nusunix3.nus.sg
bitnet: eng20009@nusvm.bitnet
"Everything is possible for him who believes" (Mark 9:23)
---------------------------------------------------------
Newsgroups: comp.lang.c