HDTenEightyP/NetNews huggingface dataset:
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: PLEASE don't use "long long" for 64 bits + answer to letter
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 6 Apr 1992 00:35:08 GMT

In article <aFeoiB1w164w@amfent.Gwinnett.COM> amf@amfent.Gwinnett.COM (Andy Feib
us) writes:
>Without having "long long" in strict ANSI mode, is "long" 32 bits or 64 bits?

Strict ANSI mode ALWAYS requires a diagnostic for occurences of "long long",
although pedantically it is possible to still have "long long" along with
the diagnostics, so pedantically your question isn't redundant....

Regardless, in strict ANSI mode:  maybe yes, "long" is 32 bits or 64 bits,
or maybe no, "long" isn't 32 bits or 64 bits.  It might be 36 bits or 60 bits
or 128 bits or anything else that's at least 32 bits.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: un106337@wvnvms.wvnet.edu
Newsgroups: comp.lang.c
Subject: C Books
Date: 8 Apr 92 17:31:56 GMT
Organization: West Virginia Network for Educational Telecomputing



Can anyone recomend a good C book?  I would like to teach myself C over the
summer for a compiler class I am taking next fall.  If anyone knows of an easy
to understand, yet complete introductory to C programming text I would
appreciate the information.


THANKS
Bill



                      +----------------------------------+
                      |          BILL CAWTHORNE          |
                      +----------------------------------+
                      | EMAIL: UN106337@WVNVMS.WVNET.EDU |
                      |      : UN032315@WVNVMS.WVNET.EDU |
                      +----------------------------------+
Newsgroups: comp.lang.c
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Subject: Re: Need help on how to use fflush(stdin)
Bcc:  mitchell
Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell)
Organization: Motorola, Mobile Data Division - Seattle, WA
Date: Wed, 8 Apr 1992 14:16:49 GMT

in comp.lang.c, CONSLT24@Zeus.unomaha.edu (Issa El-Hazin) said:

>Does anybody know how to flush the stdin in VMS 'C'?
>[...]
>I'm doing something
>similar to the next program and I can't figure out why it's not working.
>
>
>#include <stdio.h>
>
>main()
>{
>
>char test;
>int array[10];
>
>	printf("\n Type a letter: ");
>	scanf("%c",&test);	/* wait until I'm ready		      */
>
>	sleep(5);		/* while waiting for 5 seconds        */
>				/* Type a string and press <enter>    */
>
>	fflush(stdin);		/* flush standard input (keyboard)   */
>
>	scanf("%s",&array);	/* read what's in the input buffer    */
>
>	printf("\n%s",array);	/* will print the string typed before */
>				/* flushing the stdin		      */
>}

The only reference to ansi C I have handy at the moment is PJ Plaugers
"Standard C" Quick Reference Guide, which gives a very brief description
of library functions, but no background verbage and no quotes from the
standard.  It says the following about fflush():

  int fflush(FILE *stream);
  The function writes any buffered output to the file associated with
  the stream and returns zero if successful; otherwise, it returns EOF.
  If stream is a null pointer, fflush writes any buffered output to all
  files opened for output.

I don't know about any pecularities of VMS 'C' in particular, but I
think the answer to this is that fflush(input_stream) is nonportable
if its return value isn't checked and error returns are not handled.
Some systems will flush unread data in an input stream, and should
return 0; some will leave unread data unflushed, and should return EOF.

I checked the FAQ list and couldn't find any info on this.  It seems
to come up often enough that an entry on the subject would be a good
idea, I think.

-- 
mitchell@mdd.comm.mot.com (Bill Mitchell)

Newsgroups: comp.lang.c
From: amaluf@Monet.McRCIM.McGill.EDU (Rodrick Ameen Maluf)
Subject: help
Organization: McGill University, McRCIM
Date: Thu, 16 Apr 92 20:01:22 GMT



Hi,

I am facing some problem on the sgi machines (mips processor)).

the problem is the following:

I want to call a function for which I have to determine the arguments
from the user input. Once I have determined the arguments ( their number
as well as their type ) I am having problem building the stack for the
function that I want to call with those arguments.

PS:
 I have tried using the ``asm'' directive provided by gcc but I run into
 problems with ``double'' type arguments.


thanks for any help,

Ameen

-- 
__________________________________________________________________
Ameen Maluf:                 amaluf@larry.mcrcim.mcgill.edu
                             McGill Research Center for Intelligent Machines
                             Mcgill Univeristy, Montreal, Canada
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Binary mode stdin
Date: 9 Apr 92 13:59:53 GMT
Organization: University of Helsinki

brianm@cc.gatech.edu (Brian N. Miller) writes:
>Often in UNIX:  Get the process's tty name.  Or determine the file name
>                 of the process group's console IO port.

Won't work if the standard input has been redirected.  I think the
original poster was going to do exactly this.

>   For MS-DOS:  When in doubt, use BIOS calls.  RT(F)M.   

I don't agree.  When possible, you should use the standard I/O library
(a.k.a.  <stdio.h>).  It's portable, more stable (works even on future
machines with possibly different BIOSs), more user-friendly (allows
redirection), and is easier to use.

It does have the drawback that you apparently can't use binary I/O for
stdin/stdout, at least not portably.

>        C doesn't define IO. _____/        \______ Never.

The language proper does not, but (in case you hadn't noticed :) there
is a pretty large and useful library that covers, among other things,
basic I/O.

--
Lars.Wirzenius@helsinki.fi
Newsgroups: comp.lang.c,comp.std.c
From: sjc@borland.com (Steve Correll)
Subject: Re: "long long" for 64 bits
Organization: Borland International
Date: Mon, 13 Apr 1992 07:07:45 GMT

In article <ERU.92Apr10174321@tnso04.tele.nokia.fi> eru@tnso04.tele.nokia.fi (Erkki Ruohtula) writes:
>Has anyone considered what this "32-bit long, 64-bit long long" regime
>does to the "fseek" (and "lseek") function?

Yes. The folks at Amdahl have, for example. Ask them. What seems to have
escaped many participants in this discussion is that certain real users have
years of experience with this design decision--more years, in fact, than
_anybody_ has with that young whippersnapper, the ANSI C standard!
From: storrs@milton.u.washington.edu (Storrs Albertson)
Newsgroups: comp.lang.c
Subject: HELP Menus with Mice on PC with Microsoft C
Summary: HELP Menus with Mice on PCs with Microsoft C
Keywords: HELP, Menus, Microsoft, C, Mouse, Mice, PC
Date: 6 Apr 92 06:07:32 GMT
Organization: University of Washington

I'm new to C programming and wondered if someone would be
kind enough to mail me some sample code which shows how
to code a typical MENU (for any application) with Mouse
control (i.e. in addition to using keys to choose Menu
options).  I'm working on a PC with the Microsoft compiler
if it makes a difference.

Alternately, perhaps someone knows of such a code on a
board that I could download.


Thanks in advance,

alberts@apl-em.apl.washington.edu
Newsgroups: comp.lang.c
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: red/black trees
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Mon, 13 Apr 92 23:38:38 GMT

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.

I believe that the latest copy of Dr. Dobbs' Journal (Bear in mind
this is Canada, and the "latest" copy may be several years out of date
due to Canada (Snails-are-faster: I just got a Christmas card returned
due to addressee-not-known. The card was mailed TWO years ago, and
was mailed within Toronto TO Toronto...) Post) has one as the cover
article. 

The artwork on the cover, if my ten second scan of the article is correct,
is incorrectly colored...
Hopefully, the code they provide is better than the artwork.

Bob

Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
From: hendrik@vedge.UUCP (Hendrik Boom)
Newsgroups: comp.lang.c
Subject: Re: long long long long long madness
Date: 9 Apr 92 20:18:04 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

n9046319@henson.cc.wwu.edu (Jeremy Corley) writes:
: jbc@hpcuhe.cup.hp.com (Jeff Caldwell) writes:

: mean the same thing.  No need to rewrite code, but make it simple to
: declare _big_ variables.
: 
: int(64) x;
: float(256) y;

ANSI already has syntax like this in bitfields.
It looks like
	int x:64;
	float y:256;
-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.uucp,  iros1!vedge!hendrik
at home:	uunet!altitude!ozrout!topoi!hendrik
Newsgroups: comp.lang.c
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: Interpreting Escape Sequences
Organization: (EVIL!)
Date: Wed, 15 Apr 1992 00:39:44 GMT

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

| A seemly simple problem/question/situation has been baffled; note the
| following C program:

| /* ptest.c */
| main(int ARGC, char *ARGV[])
| {
|     printf(ARGV[1]) ;
| }

| This acts something like a Unix echo command.  Note that I am using a
| variable for the printf format directly.  

(A bad thing to do, since calling this program with an argument
containing "%s" or "%d" will cause it to go off into never-never
land.)

| The problem is that I want to
| be able to pass this program escape sequences and have it correctly
| 'expand' them for me.  But if I call it like this:

|   ptest "one\ntwo"

| it outputs

|   one\ntwo

| without expanding the newline as I would expect.

Escape code interpretation is something done at compile-time, rather
than something that C routines such as printf() do by themselves.
Print out the raw contents of any string you declare, any way you
like, and you will see that all "\n" have been changed to a single
newline character; the same for "\r" and "\t" et al.

You'll have to do this yourself if you really want backslash sequences
expanded by your program; something like this may help:

if (*p++ == '\\') {
	switch (*p) {
	case 'n':
		putchar('\n');
		break;
	case 't':
		putchar('\t');
		break;
	default:
		putchar('?');
		break;
	}
}
-- 
robert earl		rearl@piggy.ucsb.edu

"eenie, meenie, chili beanie, your lucky number is... C!" ---Kelly Bundy
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: printf() questions
Organization: D'Arcy Cain Consulting
Date: Mon, 6 Apr 1992 20:10:06 GMT

pfcouvares@amherst.edu writes:
>NAME_SIZE. (i.e. printf("%-25s",name) ... except with NAME_SIZE where 25 is)

You could do:
    printf(%*s", -NAME_SIZE, name)
however since NAME_SIZE is known at compile time I feel that the compiler
should be handling this.  Here is a way to let the preprocessor do it:

#define num_str(x) #x
#define fmt_str "%-" num_str(x) "s"
...
    printf(fmt_str(NAME_SIZE), name);

However NAME_SIZE cannot be an expression.

In really complicated situations you could write a separate program which
writes out header files for use by other programs.  Make can handle this
easily.

>2) If you indicate a field, and the string turns out to be longer, printf will
>print the entire string anyway. Is there any way to make printf truncate the
>string so that the field is absolute even if the string is longer?

See format precision in your manual.

-- 
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  |
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Clearing the screen.
Date: 7 Apr 92 02:09:44 GMT
Organization: SMDS Inc., Concord, MA

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:
> >In many versions of UNIX, and in many other operating systems there is
> >a library routine called clear which will clear the screen -- surprise!

> Are you talking of the clear that is part of curses?  In any case, the
> function needs to have similar knowledge (termcap, terminfo, or the
> like) built into it in order to work.

Please.  On any particular OS either there is a screen clear library routine
or this isn't.  If there is one, it usually called clear.  I know from nothing
about DOS so I don't know if there is one there.  However I have used about
30 implementations of UNIX, VMS and PRIMOS, and in the overwhelming majority
of implementations there is either a library routine called clear or a system
routine called clear.

If it's there you don't need to know how it works.  Termcap, shermcap,
who cares?  Does the routine exist or doesn't it?  Are there restrictions
or aren't there?  That you need to know.

> >Finally writing a formfeed character to stdout will clear the screen.

> A common fallacy.  It will not (trust me, I tried it).

My apologies -- *will* should be *may*.  It won't on most scrollable windows.
It will on all glass tty's and glass tty emulations that I've seen.  Thus
this is being typed on a 386 running an antique version of ESIX; there is
no clear command.  Formfeed works on it.  It also works on a SUN running
a shell window under suntools.  If memory does not fail me, it works fine
on a VT-100.
-- 
Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: declaring functions (was Re: serious cube root library bug)
Date: 16 Apr 92 09:54:59 GMT
Organization: University of Helsinki

bright@nazgul.UUCP (Walter Bright) writes that Zortech C has a switch
for warning about calling undeclared functions. 

How about a switch that warns about functions that are defined but have
not previously been declared?  This would be useful for catching missing
prototypes in headers or missing includes for headers, and therefore
make it more difficult to have prototypes and definitions out of sync.

--
Lars.Wirzenius@helsinki.fi
From: umsfjban@bill.oscs.montana.edu (Jeff Banfield)
Newsgroups: comp.lang.c
Subject: LISP like list functions
Date: 14 Apr 92 16:09:40 GMT
Organization: Montana State University, Bozeman  MT

I'm trying to rewrite some alogrithms in C that were developed in LISP and rely
rather heavily on the list features in LISP (list, append, nconc, union,
intersection (the algebraic union and intersection), remove, ...).  I can
probably implement these functions with linked lists but, rather than 
reinvent the wheel, I thought I'd check first and see if anyone has already
written a set of C functions (or knows of a source code archive) to create,
dispose of and manipulate lists.

If there is enough interest (and some good code) I'll summarize and post
the results.

Jeff Banfield
umsfjban@bill.oscs.montana.edu
Newsgroups: comp.lang.c
From: spencer@phoenix.Princeton.EDU (S. Spencer Sun)
Subject: Re: red/black trees
Originator: news@ernie.Princeton.EDU
Organization: Princeton Univ. Class of '94
Date: Mon, 13 Apr 1992 05:58:09 GMT

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.

... try also _Algorithms in C_, Robert Sedgewick, Princeton University :-)
----------
Spencer Sun - Princeton Univ. Class of '94 - Dept. of Computer Science
Clockwork Orange (Princeton Ultimate) (when I bother to show up for practice)
Playing bridge is like having sex.  You don't need a partner if you
have a good hand.
From: apyted@ubvmsb.cc.buffalo.edu (T. Steegman)
Newsgroups: comp.lang.c
Subject: Douglas/Peucker Algorithm
Date: 8 Apr 92 04:52:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41

Help! Does anyone out there know a simple c or c++ program that emulates
the Douglas/Peucker line simplification algorithm? If you do    or know
where I might find such a thing, please email me at the above address or
at ts3041@albany.edu. Thanks a whole ton in advance!

TDS
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Is the address of a global a constant?
Date: 8 Apr 92 11:39:12 GMT
Article-I.D.: dog.22569
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

[various questions about &x being constant]

The problem here is that there are about a zillion different `kinds' of
constant.  The C standard devotes over a page to section 3.4, `Constant
Expressions', and refers off to various other sections for exceptions
and explanatory text.

Syntactically, a constant-expression is just a conditional-expression
(something of the form a?b:c or any of the things that are legal in
that position).  The standard lists a bunch of things that prevent an
expression being constant, such as assignment, function-call, and comma
operators, so it is sometimes easy to say that something is *not* a
constant expression.  The exact details, however, are harder to pin
down.  In particular, p. 57 says:

	An implementation may accept other forms of constant expressions.

(line 1).  Thus, acceptance of any particular expression by any
particular compiler is no help in deciding whether something is actually
a `constant expression'.

The address of a static or global variable, or the same with an
integral constant added or subtracted, is explictly allowed as an
`address constant'; address constants are explicitly allowed as
initializers.  This means that

	/* foo.c */
	int a[10], *ip = a + 5;

is legal.  The standard does not, however, allow you to assume that

	&a[5] - &a[0]

is a constant expression.  Page 57 says it *might* work, and in gcc
it does.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.lang.c
From: rfries@ub.com (Robert Fries)
Subject: Re: passing structure to a function
Organization: Ungermann Bass
Date: Tue, 7 Apr 1992 18:31:10 GMT

In article <52701@mimsy.umd.edu> dong@umiacs.umd.edu (Dong Chen) writes:

>Hello,

>I have a lot of fuctions doing processing for some type of
>structures. Now as concern of efficiency, is it better to
>pass the structures as a pointer or just pass the structure
>itself ?

>something like f(struct S a) vs. f(struct S *a).

In general, it's more efficient to pass pointers. Passing
a structure is usually (always?) done by making a copy of the
struct somewhere (usually on the stack), this copying takes time. 
The actual size of the structure will probably be a factor here.

The choice between the two involves some other considerations. 
If the function uses the members of the struct for temporary
variables, structure passing may be appropriate. If changes
MUST be made to the original structures, pointers MUST be used.

In your case, if you have an existing, working, program, using
structure passing, it's easy to convert to pointers. The other 
way around may be more difficult (or impossible.) Try it, if
it 'helps', fine. Otherwise, little is lost.

It just occurred to me that an optimizer could probably make this
choice transparently, based on whether the structs are never
modified in the called function. Does anybody know if this is done?

Robert
From: sweeney@husc3.harvard.edu
Newsgroups: comp.lang.c
Subject: Re: Dictionary of Spellings
Date: 16 Apr 92 17:08:08 GMT
Organization: Harvard University Science Center

We need a dictionary of spellings to test some linguistic learning 
algorithms. In particular, we are seeking an ASCII file of several 
thousand unique words, with or without affixes. 

Attempts to produce such a file from random documents fails to produce a 
high number of unique words. The DEC PDP-10 (about 10 years ago) used 
such an ASCII file of spellings. Does anyone have an ASCII file of 
words?

If anyone can provide such a file or have any pointers, please contact
me. Thank you for your assistance.

-Latanya Sweeney
email: sweeney@husc3.harvard.edu
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: Redirecting output
Date: 14 Apr 92 17:40:55 EDT

nestorak@eregion.endor.cs.psu.edu (John  Nestoriak) writes:
>I have a program which at various points spits stuff out using printf.  Of
>course when we got the second part of the project we were told that we need
>to spit it out to a file.  Is there a way that I can redirect stdout to a 
>file from within the program?  I need to send it to one of 4 different files
>depending on which of 4 child processes creates the output.  I tried:
>   output = fopen("out1","w");
>   stdout = output;
>But the compiler barfs saying that stdout is an illegal LHS.  What to do?

See freopen(), now showing in a C manual near you.
From: eric@pencom.com
Newsgroups: comp.lang.c
Subject: Re: C Structures
Date: 17 Apr 92 13:22:44 GMT
Article-I.D.: pencom.1992Apr17.132244.5409
Organization: Pencom Software

In article <1992Apr16.210831.13969@dcs.qmw.ac.uk> aali@dcs.qmw.ac.uk (ALI)  
writes:
> 
> I have a structure thus:
> 
> struct this { 	int x;
> 				int y;
> 			};
> 			
> I want to declare an array called temp of type struct this ie:
> struct this temp[10];
> 
> However, I want to declare temp in my main() procedure. This is 
> because the size of the array is figured out from a file which
> contains z number of elements.The file is read by a procedure called in 
> the main() procedure. So my final declaration in my main() procedure is 
> supposed to be:
> 
> struct this temp[z];
> 
> where z is an int.

Sorry, but dynamic allocation is not intrinsically supported in ANSI C.
Use malloc instead.

    struct this *temp ;
    temp = malloc(z * sizeof(struct this)) ;
Newsgroups: comp.lang.c
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: QUESTION on suppressing warning message: unused parameter
Keywords: compiler warnings suppressing
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Thu, 16 Apr 1992 22:55:38 GMT

In article <74057@netnews.upenn.edu> jim@heart.circ.upenn.edu (Jim Streicher) writes:
>[I have a function with a (deliberately) unused parameter, so I do this:]
>  c = c ; /* suppress warning, hopefully no side effects */
>Questions: Does this have any side effects? Is it bad style?

And what are you going to do when a future release of the compiler adds
warning messages for "variable c is set but never used again" and perhaps
even "variable c assigned to itself"?  (Yes, I've used compilers that notice
such trivia.)

I disrecommend this practice.  Find some other way to suppress the warning,
or just ignore it.  In any case, comment the code appropriately.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint