HDTenEightyP/NetNews huggingface dataset:
From: somerville@BAEPV2.NCSU.EDU (SOMERVILLE)
Newsgroups: comp.lang.c
Subject: Re: Supressing warning messages in BC++ 3.0
Date: 16 Apr 92 13:19:59 GMT
Reply-To: somerville@BAEPV2.NCSU.EDU (SOMERVILLE)
Organization: North Carolina State University

I tried to send e-mail, but it bounced,
"jim@heart.circ.upenn.edu" asked about supressing
warning messages, and I reply:

  Since you are using Borland C++, you have basically two methods to 
supress the warning:
Method 1:

#pragma warn -par
void foo ( int a, int b, int c )
{
  /* No warnings for unused parameters
     will be generated here!
  */
}
#pragma warn +par

The #pragma warn directive can be used this way to supress all
kinds of warnings.

Method 2:
You can also compile the source as a C++ program, with
the idea of using C++ as a better C (A good idea if you are
not already moving to C++!) In this case, C++ provides a
simple method for dealing with unused parameters:

void foo ( int a, int b, int )
{
  /* You don't need the third paramter? (yet?)
     Fine, just don't give it a name,
     and you can't use it.
  */
}

The second method is very clean.  I feel it's important to
supress warning messages after you have verified that the
code is actually what you intended.  When someone else
compiles your program, they will have to investigate all
warnings.  Even as you develop your program, it is far better
to compile with no warnings than to always be thinking, "
Three warnings... Ok, I know what those are, so I wont
worry about them..." and then as you choose Run from
the menu you think, "or was that only two I had last time..."

I would object to the technique of using the unwanted
paramter in some meaningless expression just to avoid the
warning.  In the end, it will only confuse you and others 
who stare at the offending expression long after its 
original purpose is forgotten. ( or worse, your successor will
post the expression to comp.lang.c thinking it is some clever
trick!)
 
Have fun.
--
Garth Somerville
somerville@bae.ncsu.edu
From: jim@heart.circ.upenn.edu (Jim Streicher)
Newsgroups: comp.lang.c
Subject: QUESTION on suppressing warning message: unused parameter
Summary: how do I get rid of a compiler warning
Keywords: compiler warnings suppressing
Date: 15 Apr 92 01:58:00 GMT
Followup-To: comp.lang.c
Organization: Department of Bioengineering

I have a quick question about suppressing warning messages.

I get a warning message in the following function:

/* ----- begin example code ----- */
/* function prototype */
int add(int a, int b, int c);

/* function definition */
/* add() - adds two numbers  and returns the sum */
int add(int a, int b, int c)
{
  int sum=0;
  sum = a + b ;
  return(sum)
}
/* --- end example code ---- */

The warning says I have an unused parameter, c, in function add().

The reason I have c declared is that I have a whole bunch of
functions that do similar things, and I would like to have
the functions called in an identical way. Some of the functions
use c and some don't.

I have found the warning messages to be a nuisance, so in the
functions that don't use the extra parameter, I do this:

/* add two numbers */
int add(int a, int b, int c)
{
  int sum=0;
  
  c = c ; /* suppress warning, hopefully no side effects */
  sum = a + b ;
  return(sum)
}

Questions: Does this have any side effects? Is it bad style?
           Is there a better way of getting rid of the warning?


As I see it, I have three options:
 1) ignore the warning message
 2) take out the extra parameters in the functions that don't use it
 3) do the c = c thing. So far I haven't seen any problems but it
    sure looks silly.


I happen to be using Borland C++ with all warning messages
turned on. 

Thanks in advance for any suggestions.
Jim

-------------------
Jim Streicher
jim@heart.seas.upenn.edu
From: dd3e+@andrew.cmu.edu (Danny R Dalal)
Newsgroups: comp.lang.c
Subject: Info Re: Header files and the like
Date: 16 Apr 92 18:26:40 GMT
Article-I.D.: andrew.UdvQPU_00WBL44pR12
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Hey, I have a question.
(A couple actually)

1.>  Where can I get the full FAQ thing?

2.>  Is there a document that defines how to modularize a big program? 
I'm tired winging it (trial and error: maybe I should put the data
structure here and the externs here and include the .h here... etc...). 
I want to know exactly how it all works.  I looked in K&R but that was
strangely lacking.  Any insight and especially references would be
greatly appreciated.

3.>  What tools would you (in your professional oppinion) say are what
you need to KNOW inorder to develop any decent, usable, maintanable code
fast and friendly?  (I mean stuff like make, debuggers and tools that
manage the development of a prog, what is lint?)


Thanks alot:


____Dan@CMU.EDU

-------------------------------------------------------------------------
Disclaimer and quote type thing....

" I never said that?"

"The early worm is dead."   --someone...

---------------------------------------------------------------------------
From: michel@vedge.UUCP (Michel Trudeau)
Newsgroups: comp.lang.c
Subject: TD386 and more than 16megs or ram
Date: 15 Apr 92 14:45:24 GMT
Article-I.D.: vedge.28568
Organization: Visual Edge Software, St. Laurent, Quebec

When I run td386 on my 486DX2/50 Mz with 32 megs of
ram, the machine reboots itself.

When I run td386 on the same machine with 16 megs of
ram, then the machine is alright.

Did anyone have ever heard about such a problem,
is there any fix ???

Thanks
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: Initialisation code in ANSI C.
Date: 14 Apr 1992 23:59:46 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world
NNTP-Posting-Host: telecaster.think.com

In article <1992Apr15.105431.7429@waikato.ac.nz> bwc@waikato.ac.nz (Ug!) writes:
>Arthur Rubin writes:
>> What is wrong with:
>> 
>> int module(int arg1,float arg2)
>> {
>> static int module_INIT= 0;
>> 
>>     if(!module_INIT) {
>>         ...intialize module...
>>         module_INIT = 1;
>>     }
>
>There's a problem with that.  The module this is for essentially must first
>allocate the screen device before any reading/writing to the screen may take
>place.  (By reading or writing, I am referring to pixels).
>
>As you can imagine, having the code which draws each pixel having to check each
>time whether it is initialised is not a "Good Thing" (tm).

Here's another idea:

Instead of calling the functions directly, call them through function
pointers.  All the function pointers would be initialized to a function
that calls the initialization routine and then calls the corresponding real
function.  In addition to allocating the screen device, the initialization
routine would reset all the function pointers to refer to the real
functions.

The code would look something like this:

In draw_pixel.c:

int (*draw_pixel)(int x, int y) = initial_draw_pixel;

static
int real_draw_pixel (int x, int y) {
    /* all the real work */
}

static
int initial_draw_pixel (int x, int y) {
    initialize();
    return real_draw_pixel(x, y);
}

void initialize (void) {
    allocate_screen();
    /* other initialization ... */
    draw_pixel = real_draw_pixel;
    erase_pixel = real_erase_pixel;
    /* etc. */
    return;
}
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: string representation
Date: 14 Apr 92 20:48:02 GMT
Article-I.D.: ima.1992Apr14.204802.13304
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <1992Apr14.120556.7276@cl.cam.ac.uk> ag129@cl.cam.ac.uk (Alasdair Grant) writes:
>>In article <1992Apr13.024026.24553@ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:
>>>Use whatever model best suits your need.  In most of my applications,
>>>maintaining the length information would be unnecessary overhead.
>
>But only O(1) overhead.  I can live with a program that runs twice as slow,
>but not one that runs 100 times as slow.

But why make it run slower at all, if it isn't necessary?

Btw, a quick check of my source code that uses strlen() suggests that the
simplest improvement would be to have a version of fgets() and strcpy() that
return the length or the end-pointer, rather than the redundant copy of the
buffer-pointer.

>Besides, a good compiler will be able to optimise out the maintaining of a
>string length...

Hmm, you'd have to do something like link-time optimization in order to
eliminate the extra maintenance in setting up the return value of a
string-valued function.  It's possible, though.

>But the real point is that the programmer should not have to know how strings
>are stored; the compiler should be free to use the fancy techniques used in
>languages like Snobol, Icon and Rexx, and to generate code for expressions
>like
>  a = a || substr(b || right(c,len(d)),index(s,"a"))
>in whichever way it chooses.

I guess I'll agree that, if C were to add a true string datatype, the internal
representation should remain unspecified.  It *is* necessary to specify who's
responsible for maintaining the storage (with C's low-level pointer-to-char,
it's usually the user, or sometimes the library function), and under what
conditions two string objects might share space in a manner which is visible
to the user.  It's not a trivial decision.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
From: robert@isgtec.com (Robert Osborne)
Newsgroups: comp.lang.c
Subject: Re: using #define
Date: 16 Apr 92 15:17:35 GMT

v101q4ct@ubvmsb.cc.buffalo.edu (Brendon M McNamara) writes:
> How can I do this:
> 
> #define FILE(n)   "FILE.F"(somehow stick n in here)
> 
> func() {
>     int x;
>     for (x=0;x<10;x++) printf("\n%s",FILE(x));
> }
> 
> to create the following output:
> 
> FILE.F0
...
> FILE.F9
> 
> I think that completely defines the question without
> really asking a thing.

What you are trying to do is really bizarre but here goes:

    #define FILE(x) sprintf(malloc(30), "FILE.F%d", x)

a better solution to the actual problem might be:

    #define FileName "FILE.F"

    func() {
	int x;
	for (x=0;x<10;x++) printf("\n%s%d",FileName,x);
    }

Rob.
--
Robert A. Osborne   ...!uunet.ca!isgtec!robert or robert@isgtec.com
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: red/black trees
Date: 13 Apr 92 03:18:32 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <1992Apr12.163455.28108@dartvax.dartmouth.edu> cmcgav@coos.dartmouth.edu (Christine B. McGavran) writes:

> anyone have any c code for a red-black tree hanging around?  i'm too lazy to
> write it.

Look in `Data Structures and C Programs' by Chris Van Wyk (published
by Addison-Wesley).
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c
Subject: Re: EXPONENT
From: ctw@qopus.uucp (ctw)
Date: 15 Apr 92 04:48:52 GMT
Organization: QOPUS (Bowling Green, Ohio)

Alan Watson gurgled at All on <14 Apr 92>:

 AW> In article <1992Apr9.182908.22359@rice.edu> aisma@owlnet.rice.edu
 AW> (Ahmad Ismail) writes:

 >> I am new to the C language. Can anybody tell me how to write the
 >> following FORTRAN code in C:       a=b**(1./d)

 AW> There is no exponentiation operator in C, so use:

 AW> #include <math.h>
 AW> ...
 AW>         double a, b, d;
 AW> ...
 AW>         a = pow (b, 1.0/d);

Methinks it might be safer (in general) to do this:

double a, b, d;
...
a = pow (b, (1.0/d));
...

(With 1.0/d in parentheses -- getting into the parens habit has saved
me LOTS O' TROUBLE.  :=D  )

ttfn/ctw

--  
Christopher A. Tweney / Email: ctw%qopus@gantz.bowlgreen.oh.us
USNAIL: 622 Morton, Bowling Green, Ohio 43402
{$}
I will not be held responsible for the opinions of my computer.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: Interpreting Escape Sequences
Date: 15 Apr 92 13:46:56 EDT
Followup-To: alt.flame

andy@ian.stx.com (Andy Moore) writes:

>}'main' should end with a
>}	return 0;
>}or
>}	exit (0);
>}to be fully correct, by the way.

>Eat my shorts.  Believe it or not, some of us don't *like* C, and some
>of us write real code in the Real World (tm) and don't give a rat's
>about being 'fully correct'.

Not caring about being correct, fully or otherwise, will not look good
on your resume in the Real World (tm).  Liking C isn't your job.  Writing
programs that work (and not by accident) is.

Trivial programs to illustrate a question like yours don't need to end with
return 0 or exit(0), but if you don't bother with that formality in real
programs, they're wrong.

Also note that flaming people who try to help you, even when they offer
what you think are answers to questions you didn't ask, is not the most
productive strategy.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: ANSI C NULL with cast as a function arg generates lint warning
Date: 6 Apr 92 11:52:40 EDT

ravikm@piobe.austin.ibm.com (Ravi K Mandava) writes:
>Fo ex.:		execl("/bin/ksh", "ksh", "kill -l", (char *)NULL);
>						    ------------
>					gets expanded to
>						    (char *)((void *)0)
>	12: warning: possible pointer alignment problem, op CAST

Because this function is variadic, the compiler cannot be expected to do
the promotion to (char *).  Because NULL may be defined as 0, portable code
*must* include the explicit cast.  The potential conflict is why people
keep arguing against "#define NULL (void *)0", even though the Committee
caved in to people who falsely thought that legalizing that perversion would
make a few badly-written PC programs work better.

>	1.  Remove the cast around "NULL".
>		Ex.:  execl("/bin/ksh", "ksh", "kill -l", NULL);

Bad.  The compiler cannot be expected to do the promotion in this case.

>	2.  Use '0' instead of "NULL', but with a cast.
>		Ex.:  execl("/bin/ksh", "ksh", "kill -l", (char *)0);

The Standard guarantees that this is correct.

>	3.  Declare a temporary variable to hold a generic NULL pointer, and
>	    this variable as an argument with a cast.
>		Ex.:  void *vnullp = NULL;
>		      execl("/bin/ksh", "ksh", "kill -l", *(char **)&vnullp);

Don't do this.  I think it is guaranteed to work ("Two null pointers, converted
through possibly different sequences of casts to pointer types, shall compare
equal."), but it is ugly and unnecessary.

>	4.  Fix the "lint" program.

"Yes".  Actually, the compiler should be fixed (and, ideally, you should just
edit <stdlib.h> to replace the stupid definition of NULL with the morally
correct definition of NULL (0)).  If your vendor won't fix the compiler like
this, they should modify lint to fail to complain about casting NULL to the
desired pointer type.

>	5.  Ignore the warnings and continue the use of cast for NULL pointers.
>		Ex.:  execl("/bin/ksh", "ksh", "kill -l", (char *)NULL);

Reasonable.  This will continue to irritate you until you finally demand of
your compiler vendor that they fix it.

>Currently, I'd prefer to go with Solution 1.

As I said, Solution 1 is the only one which happens to be *wrong*.  Go with
2 or 4+5.

>P.S.:	Another thought:  maybe "NULL" macro definition should have been left
>	as '0' (instead of a generic null pinter).  I could be very much
>	wrong here as it goes against the ANCI C standard set by pundits.

No, it goes against the "ANSI C standard set by pinheads."  All the pundits
tell you to define it as 0, the way Dennis meant it to be.  (Amen)
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Is the address of a global a constant?
Date: 8 Apr 92 14:36:57 GMT
Organization: AND Software BV Rotterdam

In article <chupchup.702696624@piggy> chupchup@ferkel.ucsb.edu (Robert Earl) writes:
|OK.  I quote K&R II:
|
|"Constant expressions may not contain assignments, increment or
|decrement operators, function calls, or comma operators, except in an
|operand of sizeof.  If the constant expression is required to be
|integral, its operands must consist of integer, enumeration,
|character, and floating constants; ...  This necessarily rules out
|arrays, indirection, address-of, and structure member operations."
|
|Later it goes on to *specificially* *permit* the use of address-of for
|*initializers*.
|
|Unless the standard turned around and did something completely
|different from what is in K&R, I highly doubt that "the address of an
|object with static duration is ALWAYS a constant.".  I agree that it
|is not an integral constant expression; but what is this?
|
|case &y - &z:

This is not allowed, for reasons you just quoted here above:

`If the constant exression is required to be integral, its operands 
must consist of integer, enumeration ...'. ANSI 3.4 says the same
thing about these integral constant expressions. I'm still not
sure whether of not &x, where x is a global variable,  is a constant
expression or not. ANSI 3.4:

A constant expression can be evaluated during translation rather than
runtime [ ... ]

All, but the relocation information can be evaluated during translation
time; the linker would do the relocation calculations, but there's no
need to do any evaluations during runtime anymore ...

Jos aka jos@and.nl
From: gordon@osiris (John Gordon)
Newsgroups: comp.lang.c
Subject: Re: goto statement
Date: 12 Apr 92 21:17:48 GMT
Distribution: usa
Organization: University of Illinois at Urbana

yltang@bree.endor.cs.psu.edu (Yuan-Liang Tang) writes:


>Hi netters,

>    I know this may be trivial, but I simply couldn't find
>an answer in the FAQ list. So, here the question comes ...

>    Can I use "goto" statement to transfer control to other
>function or other module than the current function?

>    Thanks in advance.

	No, but setjmp() and longjmp() can be used for this purpose.

---
John Gordon
gordon@osiris.cso.uiuc.edu       Be a *quality* slaveowner.  Buy American!
Newsgroups: comp.lang.c
From: wittig@gmd.de (Georg Wittig)
Subject: Re: Is the address of a global a constant?
Organization: GMD, Sankt Augustin, Germany
Date: Tue, 7 Apr 1992 08:01:04 GMT

In <chupchup.702626670@piggy> chupchup@ferkel.ucsb.edu (Robert Earl) writes:

>eric@pencom.com writes:
>
>| Is the address of a global supposed to be considered a valid constant?
>
>No.  The address-of operator (&) is just an operator and does not
>yield a constant value.

So,

	int   x[9];
	int * y1 = x+7;	  /* Correct */
	int * y2 = &x[7]; /* Wrong?  */
--
"Freedom's just another word  | Georg Wittig   GMD-I8.IT   P.O.Box 1316
for nothing left to lose"     | D-W-5205 Sankt Augustin 1   (Germany)
                              |     email: wittig@gmdzi.gmd.de
(J. Joplin, K. Kristofferson) |     telephone: (+49) 2241 14-2294
Newsgroups: comp.lang.c
From: khatri@seas.gwu.edu (Anil Khatri)
Subject: C beautifier
Originator: khatri@seas.gwu.edu
Organization: George Washington University
Date: Tue, 7 Apr 1992 00:18:58 GMT

Hi! netters, here is one simple question for you all. Are any of you guys using
C Beautifier for your C programs. Do you find any other advantage of it apart 
from  easy readibility and debugging of code.


thanks in advance.......

Xref: sparky comp.lang.c:7435 comp.std.c:1779 comp.arch:4883
From: bear@harlqn.co.uk (Andy Edwards)
Newsgroups: comp.lang.c,comp.std.c,comp.arch
Subject: Re: SPAM SPAM SPAM SPAM (was Re: PLEASE don't use "long long" (was: Alph))
Date: 9 Apr 92 16:56:12 GMT
	<BEAR.92Mar31184244@godzilla.harlqn.co.uk> <ktiebjINNpqb@spim.mips.com>
Organization: Harlequin Limited, Cambridge, England


>> why don't we call 64-bit int's "wide" instead of "long long", after
>>all they *are* wider!
>
>As has been pointed out before, you are likely to get into trouble if
>you take a previously unreserved word and make it reserved, which was what
>I suspect led to (for example) gcc using long long in the first place.

Point taken, but, introducing a new type name for a new size of
storage is probably not such a bad idea. Ie we don't have to change
the semantics of all the other code we've already written just because
int is defaulted by a C compiler on a 64-bit machine to be 64 bits!

Thus storage allocation & required precision of such variables remain
the same, eg:

  int a[ 20 ]     !=  wide b[ 20 ]
  sizeof( a )     !=  sizeof( b ) &&
  sizeof( a[0] )  !=  sizeof( b[0] )

Anyway for gods sake, it's not going to break the bank and that many
programs, is it now? Have you got a program that uses the word "wide"
as a variable? No, I guess not.

Further more, strings and the string hacking functions in the C
library (according to K&R) are a real mess in C. If we have 64-bit
pointers then (in this ridiculous example) I can have a string that
could possibly contain 2^63-1 characters where the last is '\0'.

 ** For strlen, strcat, strcpy etc, all of these operations on the **
 ** string become totally ridiculous in terms of performance on a **
 ** demand paged machine, imagine if the string were 2^63-1 **
 ** characters long the machine would take a hell of a long **
 ** time paging, counting & looking through all that memory **
 ** looking for '\0' **

It's about time the string functions were all scrapped & replace with
something that was a struct, eg:

typdef struct _string {
  int length, maxlength ;
  char *string ;
} String ;

Some of us more sensible programmers have already done this anyway.

+--: Andy Edwards :----------*=================*------------------------------+
| Macintosh fire fighter,    | Harlequin Ltd.  |      uucp: bear@harlqn.uucp  |
| deity, PostScript language | Barrington Hall |     janet: bear@uk.co.harlqn |
| level 2 porter and PAP     | Barrington      | applelink: harlequin         |
| server clone originator.   | Cambridge       |     voice: 0223 872522       |
|                            | CB2 5RG         |            +44-223-872-522   |
|   *we complicate YOU*      | England         |       fax: 0223 872519       |
+----------------------------*=================*------------------------------+
From: valley@gsbsun.uchicago.edu (Doug Dougherty)
Newsgroups: comp.lang.c
Subject: Re: atexit_t ???
Keywords: Turbo C
Date: 9 Apr 92 15:39:14 GMT
Organization: University of Chicago Computing Organizations

(I tried to send this email, but it bounced)

--> To: msb@sq.com
--> Subject: Re:  atexit_t ???

>There is no "atexit_t" in ANSI C, and since that name is in the user's
>namespace, an ANSI C implementation must not define it.

>The Synopsis for atexit() in the standard is:

>	#include <stdlib.h>
>	int atexit(void (*func)(void));

I have gotten many conflicting responses to my query.  Many claim it is
an ANSIism, others, like you, claim it is not.

In any case, the solution, at least in Borland C, is to cast the arg
to atexit, to whatever is necessary (taking your life in your hands as
you do so...)

>Mark Brader			Summary of issue:  Fix FORTRAN-8x.
>SoftQuad Inc., Toronto		Committee Response:  This proposal contains
>utzoo!sq!msb				insurmountable technical errors.
>msb@sq.com			-- X3J11 responses to 2nd public review
				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

				Love that!!!
****************************************************************************
The Slug		valley@gsbsun.uchicago.edu

Adolescence, n.:
	The stage between puberty and adultery.

(THis [sic] message should be assumed to have been smiley captioned for the
humor impaired)
Newsgroups: comp.lang.c