HDTenEightyP/NetNews huggingface dataset:
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: declaring functions
Organization: D'Arcy Cain Consulting
Date: Wed, 8 Apr 1992 12:55:02 GMT

amorgan@Xenon.Stanford.EDU (Crunchy Frog) writes:
>This kinda depends on what your compiler is.  If you use gcc with the -Wall
>option you will get pestered about *every* error you make (including "Your
>code looks like shit.  Rewrite this function").  Other compilers have different
>options.  RTFM looking for "warning level" or something similar.

Ignoring the facetious remark (I've never been told that my "code looks like
shit.") what is wrong with a compiler pointing out your errors?  I suppose
you mean warnings but even then it is possible to write most code without
generating warnings.  I use the following CFLAGS in all my code:

CFLAGS = -O -Wall -ansi -pedantic -Wcast-qual -Wid-clash-31 -Wshadow \
         -Wpointer-arith -Wwrite-strings -Dscanf=DONT_USE_SCANF

and I can get most code to compile without a single warning.  It means
that I have to prototype every function before I use it and use const
when applicable.  Sometimes you can't get completely clean compiles.
Consider strchr(3):

#include	<string.h>
char	*strchr(const char *s, int charwanted)
{
	while (*s != charwanted)
		if (*s++ == '\0')
			return(NULL);

	return(s);
}

(Above based on code from Henry Spencer.)  I haven't found any way of
passing the "const char *" to "char *" without generating a warning.

My SVR4 cc with "-Xa -v -O -Dscanf=DONT_USE_SCANF" doesn't generate a
warning here but it also doesn't warn about other things such as using
a function without a prototype in scope.  I prefer the behaviour of gcc
in this.  In fact I get around it by adding the line:

#define const

in the source for these problem files and just make sure that the code
does the right thing.

-- 
D'Arcy J.M. Cain (darcy@druid)     |
D'Arcy Cain Consulting             |   There's no government
Toronto, Ontario, Canada           |   like no government!
+1 416 424 2871          DoD#0082  |
Newsgroups: comp.lang.c,comp.windows.ms.programmer
From: tjr@cbnewsc.cb.att.com (thomas.j.roberts)
Subject: Re: Please.  (Was Re: I Hope the BC++ IDE Editor Supports OLE Soon)
Organization: AT&T
Date: Mon, 13 Apr 1992 19:29:43 GMT

From article <kuede7INN40h@alhena.usc.edu>, by ajayshah@alhena.usc.edu (Ajay Shah):
> ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes:
> 
>>I'm excited about the potential for using OLE in a compiler's text editor.
>>In addition to leaving voice annotations, etc., documentation could be inserted
>>in-line.  The documentation could be diagrams, word processor text, voice 
>>samples, even animated video.
> 
> I sure hope I don't encounter your source code someday when I'm alone
> in a dark ftp site.
> 
>>Perhaps one of the reasons we programmers are often reluctant to write
>>in-line documentation is that the tools (tty-style editors) are so primitive.
> 
> A tool like Emacs can hardly be called primitive, [....]
> 
> User friendly -- you spend 15 minutes learning how to use it, and
> the rest of your life struggling to get your job done.
> [....]
> "Thrilled writing C with Emacs"

Well, I used to agree with you. Then I started using Borland's Turbo C
Integrated Development Environment (IDE). This IDE has evolved into a
truly useful environment that puts emacs to shame. I now find that working
on UNIX is a real pain (the IDE automatically positions the
editor to the character where the complier detected an error - ~90% of
the time that is precisely where I need to edit). And the error messages
even contain a (usually) comprehensible description of the error (boy,
MS-DOS/BC++ sure isn't UNIX!! (:-).

However, I, too, do not believe that animation/audio objects in source code
will help developers. As alluded to above, nothing can take the place
of an intelligent, well though out design - that takes thought, experience,
time, and effort.

Tom Roberts	att!ihlpl!tjrob		TJROB@IHLPL.ATT.COM
From: chaolin@fcit-m1.fcit.monash.edu.au (CHAOLIN CHANG)
Newsgroups: comp.lang.c
Subject: Best Compiler for teaching?
Date: 9 Apr 92 22:38:40 GMT
Organization: Faculty of Computing and Information Technology, Monash University

Dear Netter,

What compiler would you use for teaching ANSI C under DOS environment?



Chaolin
___________________________________________________________________________
Chaolin Chang, Dept of Business Systems, Monash University, Vic., Australia
Lecturer       Voice:+61 (3)565-2360  Fax(G3):+61 (3)565-5159
chaolin@fcit-m1.fcit.monash.edu.au               :-)
---------------------------------------------------------------------------
Newsgroups: comp.lang.c
From: dwh@vaxeline.ftp.com (David W. Hamaker)
Subject: Re: string representation (was: SPAM SPAM SPAM SPAM)
Organization: FTP Software, Inc., Wakefield, MA
Date: Tue, 14 Apr 1992 21:44:39 GMT

In article <1992Apr14.120556.7276@cl.cam.ac.uk> ag129@cl.cam.ac.uk (Alasdair Grant) writes:
>In article <1992Apr13.225124.22651@vaxeline.ftp.com> dwh@vaxeline.ftp.com (David W. Hamaker) writes:
>>By the way, MY favorite string format idea is a count byte, followed by
>>some string bytes, repeated as long as the current count byte has a
>>value of 255....
>But strings still have to be contiguous in memory, and it is still necessary
>to read a lot of bytes to find out the length (which affects both processor
>cache and virtual memory).

Strlen is O((N+255)/255) (C-Style int division).  It is O(1) below length 255
and the cache/virtual memory effects are moot there as well.  At the lengths
where significant thrashing effects are happening in strlen, I doubt that the
strlen component will be anything but a tiny bit in a flood.

>"Append" operations will need some tricky renormalisation of the second half
>of the string.

I don't think this is any worse than strcmp of linked substrings unless you
do some tricky renormalization on the linked form.  Which are more common:
compare or append operations?  "Renormalization" is perhaps a poor word to
use; one certainly doesn't want to implement strcat with a separated-out
normalization step.  The algorithm should operate in a "chunky" manner.

>Personally, I favour a linked-list approach.

And you complain about tricky....  ("Well-understood" is not the same as
"not tricky.')

-Dave Hamaker
 dwh@ftp.com
From: etxolpn@beppe22.ericsson.se (Ola Persson)
Newsgroups: comp.lang.c
Subject: atexit exit call order
Date: 8 Apr 92 06:21:50 GMT
Organization: Ericsson


	Hello world!

I'm using Sun ansic compiler and the function atexit. Does anybody know in
which order the exit handlers are called when i establish more than one. Is
this behaviour compatible?
From: tw@Materna.DE (Thomas Wysocki)
Newsgroups: comp.lang.c
Subject: Re: forked processes become <defunct>
Date: 6 Apr 92 12:23:44 GMT

shah@fnsony.fnal.gov (Hemant Shah) writes:

>I am writing a program (server) which forks processes as needed, the problem
>is that when a child process exits it becomes <defunct> until parent process
>dies. The program I am writing will be running forever (as long as system in
>running) and I cannot afford to have defunct processes. What do I need to
>do so that child process exits cleanly (i.e. does not become defunct).

You should catch the signal SIGCLD in the fatherprocess. When the child exits 
the system sends such a signal to the father to let him know. The child
stays in <defunkt>-status until the father takes the signal or until he dies.
Try signal(SIGCLD, SIG_IGN) at the beginning of your program or write a
small function (e.a. catch_sigcld()) which handles the signal and use 
signal(SIGCLD, catch_sigcld) instead.
Ciao, Tom

--
(   Thomas   Wysocki        \                                                \
 )   vox: +49 231 5599 222   )   Mine is the last voice that you will ever    )
(   fax: +49 231 5599 100   (      hear        (Frankie goes to Hollywood)   (
 \   e-mail: tw@Materna.DE   \________________________________________________\
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: Do you know of "switch" for "strings" ?
Date: 10 Apr 92 11:27:56 EDT
Distribution: comp.lang.c

kiran@touch.mit.edu (Kiran Dandekar) writes:
>I am looking for macros/functions/tips that will enable me to use a
>"switch" construct for strings. This is the kind of stuff I want to
>do:
>	switch ( TEST_STRING )
>	{
>	   case "foo" : call fun1();
>		        break;
>	    default:  call fun_default();

> 	}

Generally, the best way to go about this kind of thing, if the strings
you want to recognize are fairly important keywords, is something like

	i = which_keyword(string_buffer);
	switch (i) {
	case KEYWORD_1: ...
	case KEYWORD_2: ...
	}

On the other hand, if the strings aren't keywords of interest throughout the
entire program, that approach is less appealing, and you probably will have
to resort to explicit strcmp comparisons.  You could encase them in macros
like

#define SWITCH_STRING(test_string) Switch_String = test_string; if (0)
#define CASE_STRING(target) } else if (!strcmp(Switch_String,target)) {
#define DEFAULT_STRING } else {

	char *Switch_String, buf[10];

	SWITCH_STRING(buf) {
	CASE_STRING("bletch")
		printf("I think this is a really poor idea\n");
	CASE_STRING("yuck")
		printf("and it doesn't work like a real case, anyway,\n");
	CASE_STRING("bleah")
		printf("and it is as grotesque as all get-out,\n");
	DEFAULT_STRING
		printf("so you probably should just live with the language\n"
		       "as it stands.\n");
	}

See?  (note that cases don't fall through in this gimmick, and a "global"
variable is required to avoid having two arguments to the cases).
Newsgroups: comp.lang.c,comp.compilers,comp.groupware,comp.software-eng
From: bhv@areaplg2.corp.mot.com (Bronis Vidugiris)
Subject: a+++b
Organization: Motorola, CCR&D, CORP, Schaumburg, IL
Date: Tue, 14 Apr 1992 17:18:41 GMT

I'm curious about what is supposed to happen when the title expression
is evaulated.

Reading K&R suggests that since ++ is right associative, and has a
higher precedence than +, the 'correct' answer is

a + (++b)

However, actual code execution gives:

(a++) + b

on both machines I've tried.
Actual behavior makes sense with the ++ being tokenized 'left to right',
which is certainly easy to do.

I'm curious about what the 'right' official behavior is supposed to
be, or if it is undefined.  [I suppose 'right' is ANSI nowadays, though
if K&R addresses the topic I'd be interested as well.]

I'd avoid writing this in code I wanted to work reliably, natch :-)

Newsgroups: comp.lang.c
From: alan@bob.sal.wisc.edu (Alan Watson)
Subject: Re: PLEASE don't use "long long" for 64 bits + answer to letter
Organization: Space Astronomy Lab, Madison, WI
Date: Tue, 7 Apr 1992 05:26:59 GMT

In article <517@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
>In article <aFeoiB1w164w@amfent.Gwinnett.COM> amf@amfent.Gwinnett.COM (Andy Feibus) writes:
>|> Regarding ANSI compatibility, MIPS compilers have three modes:
>|> strict ansi, ansi with extensions, and K&R.  We will support long long
>|> in extended ansi and K&R, but not in strict ansi.
>|Without having "long long" in strict ANSI mode, is "long" 32 bits or 64 bits?
>
>Yes.
>
>More precisely, it is implementation defined.

And what does this particular implemetation define it to be?

Newsgroups: comp.lang.c
From: tomg@code3.com (Tom Green)
Subject: Re: Is the address of a global a constant?
Organization: 3M Health Information Systems
Date: Wed, 8 Apr 1992 15:20:42 GMT

In article <1992Apr7.140112.16390@pencom.com> eric@pencom.com writes:
>In article <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.
>
>However ....
>
>extern int foo ;
>static int *bar = &foo ;
>
>Works just fine.
>
>The C compiler treats the address of an external variable as a constant
>sometimes, but not in others.  Why?

Because the address is a runtime constant, not a compile time constant.
The assignment takes place at runtime and can be evaluated then.


-- 
Tom Green
- Life's a pain, then you die.                            _/_ __ ____ __
  "I shall be merciful and quick" - the Gorn              /  /_// / //_/
tomg@code3.code3.com                                                 _/
Newsgroups: comp.lang.c
From: Hans Ridder <ridder@zso.dec.com>
Subject: Re: Clearing the screen.
Originator: ridder@zowie.zso.dec.com
Organization: Digital Equipment Corporation - DECwest Engineering
Date: Tue, 7 Apr 1992 22:21:04 GMT

In article <1152@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
>In article <1992Apr3.223525.4050@klaava.Helsinki.FI>, wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>> In article <1150@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
>>>Finally writing a formfeed character to stdout will clear the screen.
>> A common fallacy.  It will not (trust me, I tried it).
>.... If memory does not fail me, it works fine on a VT-100.

Sorry, but your memory has failed.  A real VT100 treats a form-feed the
same as it treats a line-feed (which depends on the setting of the ANSI
Newline Mode.)  It will *not* clear the screen.

>Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 

-hans
-- 
  Hans-Gabriel Ridder				Digital DECwest Engineering
  ridder@rust.zso.dec.com			Bellevue, Washington, USA
  {pacbell,pyramid,uunet}!rust.zso.dec.com!ridder
Newsgroups: comp.lang.c,comp.windows.ms.programmer
From: eric@pencom.com
Newsgroups: comp.lang.c
Subject: Re: Is the address of a global a constant?
Date: 7 Apr 92 14:01:12 GMT
Organization: Pencom Software

In article <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.

However ....

extern int foo ;
static int *bar = &foo ;

Works just fine.

The C compiler treats the address of an external variable as a constant
sometimes, but not in others.  Why?
Newsgroups: comp.lang.c
From: bolan@sdf.lonestar.org (Bolan Meek)
Subject: Re: How do you access your mouse on using c/c++?
Organization: sdf Public Access UNIX, Dallas--unrestricted free shell access
Date: Mon, 13 Apr 1992 23:40:16 GMT

In article <17482.29e7ad32@ecs.umass.edu> matias@ecs.umass.edu writes:
>
>How do you go abouts accesing your mouse using turbo c or turbo c++.
>I know in Basic, there is a Mouse function, however don't know of any 
>for c.
>
     there are not library functions supplied with these compilers
to handle mouse funtions, probably because there is no across-the-board
standard, tho' 
the MS mouse in its driver calls are nearly de facto...
     so, you have to
	1) build functions in your program to make mouse driver calls
via int86() or int86x(), the former being sufficient for most of the calls.
	2) build yourself a library of mouse functions which you then link
into your program...


are you using a MS-compatible mouse & driver?  if so, I can give you the
parameters you need to pass via int86/x()...
From: eric@pencom.com
Newsgroups: comp.lang.c
Subject: Is the address of a global a constant?
Date: 6 Apr 92 20:15:18 GMT
Organization: Pencom Software


Is the address of a global supposed to be considered a valid constant?

i.e. gcc will not allow the following on 2 counts :

extern int a,b,c ;

int foo(int *p)
{
        switch(p)
	{
		case &a :
		    return 1 ;
		case &b :
		    return 2 ;
                case &c :
                    return 3 ;
        }
}

gcc first complains that p is not an integer.
It then complains that the switch labels are not constant.
Are these valid compiler gripes?
From: chuckb@milton.u.washington.edu (Chuck Bass)
Newsgroups: comp.lang.c
Subject: Re: red/black trees
Date: 13 Apr 92 18:47:47 GMT
Organization: University of Washington

Try this months Dr. Dobbs Journal.  It gives a pretty detailed
description of red/black  trees. I think it has souce in C or at
least an electronic location for source... to the best of my
knowledge ;-)

Chuck Bass
Cooperative for Forest Systems Engineering
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 14 Apr 92 17:08:09 GMT
Article-I.D.: dog.22703
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

In article <1992Apr13.175100.19334@Princeton.EDU> spencer@stone.Princeton.EDU
(S. Spencer Sun) writes:
>I believe that in some (most?  all?) cases (notably on the SPARC) the
>compiler will actually convert the code into passing a pointer to the
>structure in and out.  I know on the SPARC there's a place for returning
>a pointer to a struct for functions that have a struct return value...

This is just Sun's peculiar method of implementing structure and return
values.  Their approach is not at all sensible, with one exception, and
not all SPARC C compilers do it this way.  In particular, gcc implements
structure return values in a way that is incompatible with the default
SunOS C compiler.

The exception is that this allows old, broken code to catch errors
as `illegal instruction's rather than as `mysterious' faults, such
that the debugger will point directly to the error.  In particular,
something like

	/* file1.c */
	void foo(void) {
		bar();		/* bug: bar() undeclared */
	}

	/* file2.c */
	struct x { int y, z };
	struct x bar() {
		struct x v;
		v.y = 0;
		v.z = 1;
		return v;
	}

will break differently under different compilers.  (On some it will
not break at all---this being purely by chance.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: bajaj@thumper.bellcore.com (Shikhar Bajaj)
Newsgroups: comp.lang.c
Subject: Re: C Structures
Date: 17 Apr 92 17:52:38 GMT
Organization: Bellcore

<nl>
<nl>
<smaller><nl>
</smaller><nl>
<nl>
>I have a structure thus:<nl>
<nl>
>struct this { 	int x;<nl>
>				int y;<nl>
>			};<nl>
>			<nl>
>I want to declare an array called temp of type struct this ie:<nl>
>struct this temp[10];<nl>
<nl>
>However, I want to declare temp in my main() procedure. This is <nl>
>because the size of the array is figured out from a file which<nl>
>contains z number of elements.The file is read by a procedure called in <nl>
>the main() procedure. So my final declaration in my main() procedure is <nl>
>supposed to be:<nl>
<nl>
>struct this temp[z];<nl>
<nl>
>where z is an int.<nl>
>	However, it doesn`t work! Can anybody suggest how to do this<nl>
>and if I can put my definition of my structure into a header<nl>
>file?<nl>
<nl>
>Thanks,<nl>
<nl>
>Al.<nl>
<nl>
>You are right about this not working.  The space for a declaration<nl>
>such as<nl>
<nl>
>int temp[10] <nl>
<nl>
>is set aside at compile time, not run time as you need to do it.  So<nl>
>far as I can see, you have two choices (three if you count giving up :) )<nl>=

<nl>
>Use the realloc() to dynamically size your array of structures as you need<nl=
>
<nl>
>Declare an array of structures of a size beyond the max you ever think<nl>
>it will hit, and only use parts of it as you need to.<nl>
<nl>
<nl>
>Solution 1 is nicer, but more difficult to implement<nl>
>Solution 2 is quick, dirty and wasteful.  enjoy.<nl>
<nl>
<nl>
>SMM<nl>
<nl>
A third solution is to declare an array of pointers, a la, struct this *temp[1=
00].<nl>
This way you don't have to allocate a large chunk of memory unnecessarily.<nl>=

Just malloc() what you need.  This is just a variation of Solution 1.<nl>
<nl>
<nl>
Shikhar<nl>
<nl>
<nl>
<nl>
Newsgroups: comp.lang.c,comp.std.c,comp.arch
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: "long long" for 64 bits
Organization: /etc/organization
Date: Tue, 14 Apr 1992 16:46:43 GMT

In article <id.45VO.ZFD@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>
>Then have appropriate virtual typedefs (controlled by command line switches)
>that define int and long in terms of these. That will allow you to accomodate
>all sorts of broken programs AND allow access to any integer size. You can
>also allow "long long" to be set to one of these.
>-- 
"Add a compile option" is always a nice glib answer.  Unfortunately,
it does not really solve many problems.  Besides the particular code
module being compiled there will also be a large library of compiled
code and a number of include files with structs an unions.  These will
not be affected by the choice of compile time options, but will be
compatible with only one.  Even for those library modules produced by
the compiler implementor the cost of maintaining a different
library and interface includes for each set of compiler options can be
prohibitive.  Maintaining the library is often more expensive than
maintaining the compiler itself.  Having to build a new library for
each combination of compile options would be extremely expensive,
and would still leave a problem of the site/user libraries, compiled
with incompatible options.
Newsgroups: comp.lang.c
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: Is the address of a global a constant?
Organization: (EVIL!)
Date: Wed, 8 Apr 1992 01:30:24 GMT

jfw@ksr.com (John F. Woods) writes:

| The address of an object with static duration is ALWAYS a constant.
| It is NEVER an integral constant expression.

| OK?

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:

-- 
robert earl		rearl@piggy.ucsb.edu

"eenie, meenie, chili beanie, your lucky number is... C!" ---Kelly Bundy
Newsgroups: comp.lang.c
Subject: PL1 to C translator?
From: hamilton@peponi.wcc.govt.nz (Michael Hamilton)
Date: Mon, 13 Apr 1992 21:07:10 GMT
Organization: Wellington City Council, Wgtn, NZ

Anyone ever heard of an automatic PL/1 to C translator?  

Otherwise, would anyone who's worked with Fortran to C, or Pascal to
C, translators care to recommend one with source thats malleable?  I
don't indend to auto-translate everything, only some of the straight
forward bits - so the translator needn't be sophisticated.

Otherwise I guess I'll roll-my-own for the easy bits using yacc and
lex, etc.




-- 
________________
Michael Hamilton, Computer Services Section, Wellington City Council, P.O. Box
2199, Wellington, New Zealand.  Phone: (64) (4)801-3300  FAX: (64) (4)801-3020
Domain: hamilton@csc.wcc.govt.nz          PSImail: PSI%0530147000090::HAMILTON 
Newsgroups: comp.lang.c