HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (Peter da Silva)
Subject: Re: C standardisation issues for wide machines (was Re: SPAM ...)
Organization: Xenix Support, FICC
Date: Mon, 6 Apr 1992 16:10:58 GMT

Doesn't G++ effectively let you do this with inline assembly by creating
a new class?
-- 
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"
Newsgroups: comp.lang.c
From: pierre@cs.UAlberta.CA (Pierre Honeyman)
Subject: Re: goto statement
Organization: University of Alberta, Edmonton, Canada
Distribution: usa
Date: Fri, 17 Apr 1992 02:27:01 GMT

I believe you would have to use a longjmp, on the PC anyways, on Unix I 
don't know. Do it in assembler :)

Pierre
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: using #define
Date: 14 Apr 1992 04:58:55 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Apr13.212232.2709@acsu.buffalo.edu> v101q4ct@ubvmsb.cc.buffalo.edu (Brendon M McNamara) writes:
>How can I do this:
>
>#define FILE(n)   "FILE.F"(somehow stick n in here)

First of all, don't use "FILE" as the name of this macro, since that's used
by stdio.

Try:

#define FILEN(n) "FILE.F" #n

In an ANSI C compiler, the # preprocessor operator turns the following
token into a string, and two adjactent string literals are automatically
concatenated.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: dj1l+@andrew.cmu.edu (Demian A. Johnston)
Newsgroups: comp.lang.c
Subject: Re: C Structures
Date: 17 Apr 92 17:43:23 GMT
Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.c: 17-Apr-92 Re: C Structures by James
R. Seamans@hrmis.c 
>        main(){
> 
>                struct this *temp
>                .
>                .
>                .
>                get z from somewhere...
> 
>                temp = (this*)malloc(z * sizeof(this));
> 
> 
>        }
> 
>my $.02

    In fact ANSI has defined a macro/function to make this even more readable:

    CALLOC

    temp=(this *)calloc(z, sizeof(this));



                                                  Demian 
                                              --->  daj+@cmu.edu
                                              --->  dj1l@andrew.cmu.edu
                                              --->  demianjn@ids.jvnc.net
From: gor@cs.strath.ac.uk (Gordon Russell)
Newsgroups: comp.lang.c
Subject: Returning the highest bit set in a long
Date: 8 Apr 92 14:17:50 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.


   I am hoping that someone out there has an algorithm for calculating
the highest bit set within a long, in terms of its bit position.
Naturally, there are two obvious solutions; ie
  (1) A loop to physically examine each bit in turn.
  (2) A look-up table.

Both of these solutions are far from satisfactory, since speed is essential
(and efficient memory usage desirable). Please help

  Gordon

+--------------------------------+-------------------------------------------+
|  Gordon Russell                |  EMAIL     : gor@cs.strath.ac.uk          |
|  L13.13a, Livingstone Tower,   |  TELEPHONE : 041-552-4400   Ex 3703       |
|  University Of Strathclyde,    |  FAX       : 041-552-0775                 |
|  26 Richmond Street,           +-------------------------------------------+
|  Glasgow, G1 1XH               | Spelling mistakes within this document are|
|  Scotland, UK                  | caused by internet compaction algorithms. |
+--------------------------------+-------------------------------------------+
Newsgroups: comp.lang.c,comp.windows.ms.programmer
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: string representation
Date: 14 Apr 92 20:24:51 GMT
Article-I.D.: ima.1992Apr14.202451.13085
Organization: Interactive Systems, Cambridge, MA 02138-5302

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

But this means that a substring of a string is not a string, so the cdr()
operation (O(1) with standard strings) can't be done without either copying or
destroying the original string; and you can't extend a string without having a
pointer to its beginning (the existence of strcat() notwithstanding, I almost
always extend a C-string by using strcpy() onto its end-pointer).

If I wanted a general-purpose string object, including the ability to
non-destructively name arbitrary substrings (not just trailing substrings),
I would probably use
	class Buffer { int refcount; size_t alloclen; char *body; };
	class String { Buffer *buf; size_t pos, len; };
or something functionally equivalent to it.  (All of the size_t members could
just as easily be pointers into body.)  I would prefer to do it in C++ (hence
the "class" keyword), with appropriate protection on the members, but it's
easy enough to emulate it with careful C.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
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 07:28:36 GMT

chupchup@ferkel.ucsb.edu (Robert Earl) writes:

| wittig@gmd.de (Georg Wittig) writes:

| | 	int   x[9];
| | 	int * y1 = x+7;	  /* Correct */
| | 	int * y2 = &x[7]; /* Wrong?  */

| I was going to say that both are correct just because more latitude is
| given for constant expressions as initalizers, but when gcc compiled

| int g[&x[7] - &x[0]];

| with no complaints, I had to think again.  Is this gcc's mistake, or
| mine?

Mine.  "&x[7] - &x[0]" involves two addresses from within the same
object, which is guaranteed to be constant.  A construct such as

	int g[&x[7] - &y[0]];

fails.  The bottom line is this: the address of a variable is NEVER A
CONSTANT, unless 1) the variable has static duration AND 2) it is used
in an initialization or `sizeof' context.

The context of the original question was the labels of a switch
statement.  Granted, the address-of an object is still not an integral
expression, but it wasn't a constant expression in this case, either.


-- 
robert earl		rearl@piggy.ucsb.edu

"eenie, meenie, chili beanie, your lucky number is... C!" ---Kelly Bundy
From: tleylan@pegasus.com (Tom Leylan)
Newsgroups: comp.lang.c
Subject: Re: HELP Menus with Mice on PC with Microsoft C
Keywords: HELP, Menus, Microsoft, C, Mouse, Mice, PC
Date: 7 Apr 92 10:51:28 GMT
Article-I.D.: pegasus.1992Apr7.105128.19296
Organization: Pegasus,  Honolulu

In article <storrs.702540452@milton> storrs@milton.u.washington.edu (Storrs Albertson) writes:
>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

Storrs... three little words

Pseudo-code, pseudo-code, pseudo-code.

Don't program in any language until you've got the routine worked out in
a non-language specific format.  A "typical menu with mouse" routine is
not a "typical menu with mouse" routine at all but a collection of more
typical "get a key", "process a key", "display some choices", "highlight
one of them", "hey who pressed that mouse button" routines.

tom
From: chuckb@milton.u.washington.edu (Chuck Bass)
Newsgroups: comp.lang.c
Subject: Re: Redirecting output
Date: 14 Apr 92 21:26:54 GMT
Organization: University of Washington

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?

>John

You have two simple ways to fix it:

1) from the commandline run your program like this (PC or UNIX
but not on Macs)

   myprog > myfile.out

This will redirect output from stdout to the file named myfile.
This has the advantage of being quick and dirty but pretty dumb.
All output to stdout goes to the file.

2) you can have a global FILE pointer that is the current file
to write to.  Thus your fprintf's write to this file at all
times.  Then your program can easily switch any output in *any*
section of your program to write where you want it.

CURRENT_FILE = some_file;        /* open this guy first */
fprintf(CURRENT_FILE,"stuff");   /* this goes to some_file */
CURRENT_FILE = stdout;
fprintf(CURRENT_FILE,"stuff");  /* this goes to stdout */

These are other ways but these are SIMPLE to implement in a
short period of time.

Chuck Bass
From: nsdec@sun.pcl.ac.uk (Mandy Bromley)
Newsgroups: comp.lang.c
Subject: Re: C socket programming
Date: 13 Apr 92 17:10:40 GMT
Organization: Polytechnic of Central London


Try the select() call before you execute the accept(). An example can be 
found in the SunOS system manuel. The Network section in the socket tutorial.

Mandy (nsdec)
Polytechnic of Central London
From: walterm@hpwrce.HP.COM (Walter Murray)
Date: Wed, 15 Apr 1992 18:20:18 GMT
Subject: Re: maximum malloc() allocation size?
Organization: the HP Mtn.View Resp. Cntr.
Newsgroups: comp.lang.c

In comp.lang.c, jamesh@cs.umr.edu (James Hartley) writes:

> I also can't seem to locate where
> ANSI states this *if* they do, but is there a maximum size in which
> malloc(), calloc(), etc. can allocate?  

As I read the Standard, the answer is 32767 bytes.  Each memory allocation
allocates an object.  ANSI 4.10.3.  The Standard does not require an
implementation to support objects larger than 32767 bytes.  
Section 2.2.4.1.  A strictly conforming program must not exeed
any minimum implementation limit.  Section 1.7.  

So a strictly conforming (maximally portable) program will not
call malloc or calloc or realloc with a request to allocate more
than 32767 bytes.  Of course, an implementation ought to honor
requests for larger objects if it can.

My opinion only.

Walter Murray
-------------
Newsgroups: comp.lang.c
From: CONSLT24@Zeus.unomaha.edu (Issa El-Hazin)
Subject: Re: 486-50 Mhz, getting too HOT???? 
Organization: University of Nebraska at Omaha
Date: Thu, 9 Apr 1992 23:39:28 GMT
X-News-Reader: VMS NEWS 1.11

>      Has anyone out there own a 486-50Mhz ISA Machine??
>      Have you experience any over heating problem, especially in a
> non air-conditioned room?? 
>      How is it performance compared to any other low-end Unix
> Workstations??
> 

I friend just bought a (gateway200) with 1.2 gig hard disk, ATI Ultra 8514 
Video with 1MB (11.6x faster than standard VGA), 16MB RAM, 15" (1280 x 1024) 
non-interlaced monitor and he tells me that according to Norton 6.0 "system
information" bench marks it says that this machine runs 165 times faster
overall performance than an 8088 8mhz pc. I've never heard him say anything
about over heating or other problems yet. I use a  33MHz 486DX Gateway EISA
at work with 16MB ram, 330M SCSI (14ms)drive and Norton ranked it at 51 times 
faster (over all, 71x cpu only). And they say the 586's going to be out in
May, who needs them :)

Issa
From: hermann@holmium.informatik.uni-bonn.de (Hermann Stamm)
Newsgroups: comp.lang.c
Subject: Re: a parallel mergesort in C
Date: 15 Apr 92 07:37:59 GMT
Reply-To: hermann@holmium.informatik.uni-bonn.de (Hermann Stamm)
Organization: Praktische Informatik III

In article <aet.703244991@munagin> you write:
|> 
|> hi!
|> 	
|> 	i am interested in writing a parallel mergesort in C
|> 	as a way of working out a method for writing parallel
|> 	programs in general.
|> 
|> 	can anyone provide me with:
|> 
|> 		hints
|> 		short simple code
|> 		an idea of which library procedures might be useful
|> 		an idea of what primitives i should create
|> 
|> thanks people!
|> 
|> bert.

Hi Bert !

Try to use the ICC-Toolset (from Inmos), if you find someone in your
University who has the money for it (in Germany 1200,- DM for single-user
license for DOS or SUN). 

ICC is an ANSI-C version combined with libraries for parallelism on 
transputers. ICC generates Transputer-machine-code, but in the SUN-version
there exists a simulator (ISIM) for executing and debugging parallel
ANSI-C programs even if you don't have any transputer-chip.

Have fun with parallelism,

   Hermann.

hermann@holmium.informatik.uni-bonn.de
Hermann Stamm-Wilbrandt
Institut fuer Informatik III
Universitaet Bonn
Germany
From: andy@ian.stx.com (Andy Moore)
Subject: Interpreting Escape Sequences
Organization: STX, Lanham Maryland
Date: Tue, 14 Apr 1992 17:58:47 GMT

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.  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.  Could some kind soul
please give me a clue?  Many thanks...
-- 
_____________________________________________________________________________
Andy Moore         "I've given birth to eight babies; don't you talk to me
 andy@ian.stx.com   about gettin' hurt, you big ox!"  -- Fanny, "Robin Hood"
Newsgroups: comp.lang.c
From: chiang@m.cs.uiuc.edu (Heien-Kun Chiang)
Subject: M.J. Rochkind "Advan. Unix Programming" source listing?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 7 Apr 1992 23:19:25 GMT



    Just wonder whether Mr. Rochkind's "Advanced Unix Programming" source
listing is ftpable or not?

    Any information will be highly appriciated.
From: alan@bob.sal.wisc.edu (Alan Watson)
Newsgroups: comp.lang.c
Subject: Re: EXPONENT
Date: 14 Apr 92 03:22:40 GMT
Organization: Space Astronomy Lab, Madison, WI

In article <1992Apr9.182908.22359@rice.edu> aisma@owlnet.rice.edu (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)

There is no exponentiation operator in C, so use:

#include <math.h>
...
	double a, b, d;
...
	a = pow (b, 1.0/d);
Xref: sparky comp.lang.c:7535 comp.std.c:1805 comp.arch:4967
From: sah@redwood.mips.com (Steve Hanson)
Newsgroups: comp.lang.c,comp.std.c,comp.arch
Subject: Re: "long long" for 64 bits
Followup-To: comp.lang.c
Date: 13 Apr 1992 16:31:42 GMT
Organization: MIPS Computer Systems Inc.
Reply-To: sah@redwood.mips.com (Steve Hanson)
NNTP-Posting-Host: batman.mips.com
In-reply-to: jap@convex.cl.msu.edu (Joe Porkka)
Originator: sah@batman.mips.com

In article <1992Apr12.050347.7785@msuinfo.cl.msu.edu>, jap@convex (Joe Porkka) writes:
>
>The most obvious solution would be to simply make it a compiler
>switch. That is, unless the strict ANSI switch is on, "long long" would
>get you a 64bit int. The only other decision left to make then is the
>sizeof(long), sizeof(int) and sizeof(short). If no switchs (default), then
>long == 64bit, int==32bit, short==16bit
>1 switch makes int==long==64, and another makes short==32.
>
>This makes the compiler uglier but does not force any one
>design decision onto *everything*. If a given chunk of code insists
>on having sizeof(int)==sizeof(long) it would be simpler to change
>the makefiles then to change the program. On the other hand
>much existing code would be perfectly happy with sizeof(int)!=sizeof(long)
>and could be compiled that way.



Suggesting compiler switches alone as a solution is an
oversimplification of the problem since it ignores OS, libraries,
header files, and QA aspects. If you have unlimited resources you
could provide system support for all integer size combinations, but
rarely in practice is this true. For a given system I suspect we'll
see continued support for the 32bit model and one 64bit model.

-- 
UUCP: {ames,decwrl,prls,pyramid}!mips!sah    (or sah@mips.com)
USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086
From: jap@convex.cl.msu.edu (Joe Porkka)
Newsgroups: comp.lang.c,comp.std.c,comp.arch
Subject: Re: "long long" for 64 bits
Date: 15 Apr 92 05:03:28 GMT
Organization: Michigan State University

atbowler@thinkage.on.ca (Alan Bowler) writes:

>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
>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

Gee, last time I looked compiler vendors for MSDOS were suppling
no less than *FIVE* possible models (combinations of 16/32 bit
ints and pointers) for all their libraries. With properly
written libraries, you simply change the compiler options,
type "make" and they will compiler just fine.

As for system interfacing, thats easy. The system interface functions
would all need to be compiled in their largest format (for example,
using 64bits for everything appropriate). Then, for example
if you compiled with options for 32bit ints, the library that would
get linked in (which provides access to the system functions) would
deal with converting 32bit ints to 64. I sure that you can
comeup with some more problems still,  but they certainly
arn't insurmountable, and in any case this is a better solution
than simply providing only a *single* solution which only works
sometimes. This way, things aint perfect, but they sure are better.

So, in short, just providing compiler options is not a total
solution, and its more work than simply changing the compiler.
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Returning the highest bit set in a long
Date: 11 Apr 92 03:35:31 GMT
Organization: SMDS Inc., Concord, MA

In article <57204@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes:
> Assuming at least one bit is set, how about something like this:

> 	int HighBit( unsigned long number )
> 	{
> 		int bitnumber = 0;
> 
> 		if ( number > 0x0000FFFF )
> 		{
> 			bitnumber += 16;
> 			number >>= 16;
> 		}
> 		if ( number > 0x000000FF )

You can avoid the shifts -- on some architectures the execution time of
a shift varies with the number of bits shifted -- as follows:

	int high_bit(n)
		register int	n;
	{
		register int	m;
		register int	bitpos;

		if (m = (n & 0xffff0000)) { n = m; bitpos += 16;}
		if (m = (n & 0xff00ff00)) { n = m; bitpos +=  8;}
		if (m = (n & 0xf0f0f0f0)) { n = m; bitpos +=  4;}
		if (m = (n & 0xcccccccc)) { n = m; bitpos +=  2;}
		if (m = (n & 0xaaaaaaaa)) { n = m; bitpos +=  1;}
		return bitpos;
	}

The trick is that if a high order bit is set we mask out the low order
bits.  Masking is usually faster than shifting.  Also note that the
quoted code can fail on machines with sign extension shifting.
-- 
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: spencer@stone.Princeton.EDU (S. Spencer Sun)
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 13 Apr 92 17:51:00 GMT
Organization: Princeton Univ. Class of '94
Originator: news@ernie.Princeton.EDU

In article <1992Apr13.123217.13234@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>Not to say that it is better or worse to do this but you don't have
>to use pointers if changes must be made to the original:
>
>struct FOO { ... } foo;
>...
>foo = bar(foo);
>
>And bar is defined as:
>
>FOO bar(FOO foo)
>{
>  /* stuff changing foo */
>  return(foo);
>}

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...
----------
Spencer Sun - Princeton Univ. Class of '94 - Dept. of Computer Science
Clockwork Orange (Princeton Ultimate) (when I bother to show up for practice)
Be excellent to each other and party on.
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: passing structure to a function
Organization: D'Arcy Cain Consulting
Date: Mon, 13 Apr 1992 12:32:17 GMT

rfries@ub.com (Robert Fries) writes:
>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.

Not to say that it is better or worse to do this but you don't have
to use pointers if changes must be made to the original:

struct FOO { ... } foo;
...
foo = bar(foo);

And bar is defined as:

FOO bar(FOO foo)
{
  /* stuff changing foo */
  return(foo);
}

-- 
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  |
Xref: sparky comp.lang.c:7560 comp.std.c:1810 comp.arch:4990
From: msb@sq.sq.com (Mark Brader)
Subject: Re: hashing out the primes - a little experiment
Organization: SoftQuad Inc., Toronto, Canada
Date: Thu, 9 Apr 92 02:00:29 GMT

Bob McQueer (bobm@Ingres.COM) writes:
> Given any hash function, one can construct a pathological
> example which will cause collisions all over the place.  If we assume the
> usual "divide-string-modulo-table-size" hash function, you can argue that
> certain patterns in your symbols will result in collisions when the table
> size has a lot of factors.  You can have a lot of fun concocting such
> patterns.  Question is, how about with "normal" sets of symbols.

Do keep in mind here that { f0000, f0001, f0002, f0003, f0004, f0005,
f0006, f0007, f0008, f0009, f0010, f0011, f0012, f0013, f0014, f0015,
f0016, f0017, f0018, f0019, f0020, f0022, f0022, f0023, f0024, f0025,
f0026, f0027, f0028, f0029, f0030, f0033, f0033, f0033, f0034, f0035,
f0036, f0037, f0038, f0039, f0040, f0041 } might be a perfectly "normal"
set of symbols -- if the input to your program is being generated by
another program.  When writing things like compilers, at least, it
really is important that symbols whose names form an arithmetic
progression not cause worst-case behavior in the symbol table code.

This topic belongs elsewhere than comp.lang.c; I suggest starting the
discussion afresh in comp.programming and/or sci.math.
-- 
Mark Brader			"The spaghetti is put there by the designer of
SoftQuad Inc., Toronto		 the code, not the designer of the language."
utzoo!sq!msb, msb@sq.com				-- Richard Minner

This article is in the public domain.
Xref: sparky comp.lang.c:7414 misc.forsale.computers:17170