HDTenEightyP/NetNews huggingface dataset:
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Newsgroups: comp.lang.c
Subject: Re: How to broadcast messages to processes?
Date: 12 Nov 92 18:07:05 GMT
Article-I.D.: mksol.1992Nov12.180705.10602
Distribution: comp
Organization: Texas Instruments Inc

In <DAVE.92Nov12212434@gctgw.gctech.co.jp> dave@gctech.co.jp (Dave) writes:

>Howdy net,

>I'm trying to set up a package where processes (compiled C programs) can
>send each other public messages.  I've been studying my RISC/os
>Programmer's Guide, and have got through messages and pipes, and so far it
>looks like there aren't any real broadcast tools.

>I mean, when you set up a pipe or a message queue, you can make it so that
>any process can read it.  But when a single process reads the queue, that
>amount of read info goes away, and other processes won't be able to read
>it.  At least, that's what I gathered from the manual.

>What I want to do is have a mesage readable by all processes, as many
>times as they want.  I only want messages to get deleted when the channel
>goes away.

>I figured that I could do this with message queues by having the reading
>process re-send the exact same message it just read, so that it is in
>effect not removed from the queue.  But this has the problem that there is
>a finite amount of time between the read and the re-post in which the
>message does not exist on the queue.  And my hawkish little processes are
>sure to get hung up on that delay.

>Can somebody point me in a broadcast direction?

Have you considered shared memory?  If speed is that critical
(processes get hung up on the delay in message replacement) it may be
just what you're looking for.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c
From: kpv@ulysses.att.com (Phong Vo)
Subject: Re: How to print an integer as binary?
Date: Thu, 5 Nov 1992 14:05:03 GMT
Organization: AT&T Bell Labs

In article <1992Nov4.180622.6568@csd.uwe.ac.uk> th2_oate@csd.uwe.ac.uk (Tom Oates) writes:
>Assuming that:- 
>int i = 203;
>How do I display 'i' as 11001011?
>
If you were using the sfio package instead of stdio, you would do:
	sfprintf(sfstdout,"%..2d\n",i);
The second dot for %d specifies the base for output which
can range from 2 to 64. If you also want to display the base,
you would do
	sfprintf(sfstdout,"%#..2d\n",i);
to get	2#11001011.

There is a similar pattern for sfscanf() to read data in the same format.
  
Phong Vo, kpv@ulysses.att.com
AT&T Bell Labs, 600 Mountain Ave, Murray Hill, NJ07974
From: bkssmith@thunder.LakeheadU.Ca (BKS Smith)
Newsgroups: comp.lang.c
Subject: Re: Please help me with my #include mess-up.
Date: 12 Nov 1992 05:39:25 GMT
Organization: Lakehead University, Thunder Bay, Ont., Canada

In article <1992Nov11.172840.5540@news.ysu.edu> ae007@yfn.ysu.edu (Daniel Newcombe) writes:
>
>Well here is my problem:  I have these modules:
>  MOSTYPES.H - defines several types I am using in this
>    project, such as boolean, and a few structs and typedefs
>QUEUE.H - the header file for my queue class which has a few
>   inline things in it.
>   This has to include mostypes.h because it needs boolean.
>QUEUE.CPP - the rest of the code for the queues.  It includes
>  queue.h
>MAINMOD.CPP - my main module.  It includes QUEUE.H and MOSTYPES.H.
>When I compile I get a whole mess of errors saying that all sorts
>of things in MOSTYPES.H are redefined.  There are a lot more        
>modules that are going to have to use mostypes.h before it's   
>all over with.
>
>My question - how do I get this to compile, while still keeping
>the code portable and re-usable???
>

The problem is that you are actually #including MOSTYPES.H _twice_.
MAINMOD.CPP #includes QUEUE.H which #includes MOSTYPES.H, then it tries to
#include MOSTYPES.H again. A C++ compiler will choke on this.
The solution is pretty simple. Change MOSTYPES.H to this:

// MOSTYPES.H

#ifndef MOSTYPES_INCLUDED      // use whatever name you want here
#define MOSTYPES_INCLUDED   1  // as long as it matches this one
.
.
.
[put your original code for MOSTYPES.H here]
.
.
.
#endif
// end of MOSTYPES.H

Now when you try to include it the second time, the #ifndef statement is
false, so the body of your original code is not #included.
BTW, to be truly portable, _every_ header file you create should have this
safeguard.

						BKS

PS. this really should have been posted to comp.lang.c++...
 

-----------------------------------------------------------------------------
|Scotty:Captain, we din' can reference it!             |                    |
|Kirk:  Analysis, Mr. Spock?                           |                    |
|Spock: Captain, it doesn't appear in the symbol table.|bkssmith@           |
|Kirk:  Then it's of external origin?                  |thunder.LakeheadU.Ca|
|Spock: Affirmative.                                   |                    |
|Kirk:  Mr. Sulu, go to pass two.                      |                    |
|Sulu:  Aye aye, sir, going to pass two.               |                    |
-----------------------------------------------------------------------------
From: scotth@felix.filenet.com (Scott Hopson)
Newsgroups: comp.lang.c
Subject: Re: EBCDIC to ASCII Conversion
Date: 8 Nov 92 20:47:54 GMT
Reply-To: scotth@fritz.filenet.com (Scott Hopson)
Organization: FileNet Corp., Costa Mesa, CA

In article <1992Nov5.122240@betsy.gsfc.nasa.gov> giglio@betsy.gsfc.nasa.gov (Louis Giglio) writes:
>Does anyone know of a good way to convert EBCDIC characters to ASCII?
>I have the unfortunate need to transfer binary files from an IBM mainframe
>to our UNIX machines.

Once you get the files onto the UNIX machine you can just run them through 'dd'
and specify the ebcdic conversion like this.

dd if=infile.ebcdic of=outfile.ascii conv=ascii

of course you may have to setup your buffering and block sizes but the man
pages will help you.



-- 
Scott Hopson   (scotth@filenet.com)
Newsgroups: comp.lang.c
From: chaplin@keinstr.uucp (Roger Chaplin)
Subject: Re: The Correct Way To Write C if-Statements
Organization: Keithley Instruments, Cleveland, Ohio
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 9 Nov 1992 19:49:15 GMT

Mark Boolootian (booloo@framsparc.ocf.llnl.gov) wrote:
: 
: The following piece was written by Jim Minton, an aspiring C programmer.
: I convinced him to let me post it to the net.  Happy reading and flames
: to /nev/dull...
: 
: 
: 
: 		The Correct Way To Write C if-Statements
: 				by
: 			    Jim Minton

[ stuff deleted ]

: The indentation level is 4 spaces!

FWIW, I also happen to prefer 4-space indentation.

Did y'all notice, however, that the title of this piece has been
centered in the `page' by using TABs, and that each TAB is obviously
intended to replace 8 spaces?

Does Mr. Minton use the SPACE bar to indent his if statements??  He
must not be using his TAB key.

-- 
Roger Chaplin / Instruments Division Engineering / 14 million women will not
chaplin@keinstr.uucp / CI$: 76307,3506          / have the right to choose -
#include <disclaimer.h>                        / they have been aborted.
#include "disclaimer.h" /* cover all bases */ /
From: damurphy@wc.novell.com (Duane Murphy)
Newsgroups: comp.lang.c
Subject: Re: need to create a jump table
Date: 9 Nov 92 16:04:58 GMT
Organization: Novell, Inc.
X-Xxdate: Mon, 9 Nov 92 16:08:48 GMT
X-Useragent: Nuntius v1.1.1d12

In article Alice Uyeno, writes:
>I'm trying to develop a jump table.  Actually, the scenario is that I
have two 
>jump tables.  Depending on the value of a certain flag, I use one or the
other. 
> Each jump table consists of pointers to functions.  I'm wondering if it
is 
>possible to have the functions with varying number of parameters.  For
example, 
>if my jump table contains pointers to ErrorRoutine and ValidateCmd,
where the 
>prototypes for the routines are as follows:
>
>	void ErrorRoutine(int *ErrCode, struct foo * MyPtr);
>        void ValidateCmd(struct foo * CmdPtr);
>
>void (* FcnTbl[])() = {ErrorRoutine,ValidateCmd};
>
>where 
>	ptr = FcnTbl;
>
>and ptr is how the jump table is referenced.


Sometimes when you think you are developing a jump table you are actually 
developing a jump structure or rather a structure that contains pointers 
to functions.  

If all of the functions in the table take (and return) the same type and 
number of arguments then indeed you have a function table.  If, on the 
other hand, you have functions that have different numbers or types of 
parameters or return values then you could define a function structure 
instead.

The significant advantage to using a function structure in this case is 
that you will not have to cast function pointers to persuade the compiler 
to do what you think you ought to be doing.  Let the compiler help you 
and help to enforce the prototypes for the functions in the structure.  
In the long run you will benifit greatly.

Example (untested!):

struct {
	void (*error)(int *, struct foo *);
	void (*validate)(struct foo*);
} FcnTbl = {ErrorRoutine, ValidateCmd};

I hope this helps.

...Duane
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Lack of mathematical constants in (ANSI) <math.h>
Date: 9 Nov 92 03:56:40 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Nov2.044243.7529@tc.cornell.edu>, mdw@theory.TC.Cornell.EDU (Matt Welsh) writes:
: In article <15792@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
: >It was my impression that the purpose of the ANSI standard for C was to
: >standardise existing practice to the extentat that it was possible to do so.
: >I am disappointed that M_PI and friends are not in the ANSI standard, but
: >it hasn't proven fatal for me.  I enclose a shell archive that provides
: >two files:
: >	mathconsts.h	#defines the missing constants to 40 digits
: >	mathconsts.c	does some elementary checks
: [...]
: >/*  M_PI	is "pi", so cos(M_PI) should approximate -1.0  */
: >#undef	M_PI
: >#define M_PI		3.1415926535897932384626433832795028841972
: 
: Are you sure this is safe? For example, the ANSI C compiler on my Vic-20
: doesn't handle this degree of precision!

The number of digits provided is way beyond what even IEEE 754 double
precision would require.  That's partly to make the file useful on other
machines with higher precision, and partly to cover my arse; if I gave
exactly the right number of digits for IEEE 754 it'd look as though I'd
pinched them from proprietary code.  I don't know what "handle this
degree of precision" means; if the compiler doesn't accept lots of digits
in a float and round it to something within an ULP or two of whatever
precision it _has_ got, you won't be doing any serious f.p. work with it
anyway.

What's more, the mathconsts.c file included the bc(1) script I used to
generate the constants in the first place, so if you need more digits
you know where to get them.  If you need fewer digits, round 'em yourself.
From: clive@x.co.uk (Clive Feather)
Newsgroups: comp.lang.c
Subject: Re: Memory functions  -  memcpy & memmove
Date: 10 Nov 92 12:38:25 GMT
Organization: IXI Limited, Cambridge, UK

In article <BxB88A.1Au@portal.hq.videocart.com> dfuller@portal.hq.videocart.com (Dave Fuller) writes:
> write your own memmove (different name of course).
> lets say you call it  moveit(char * dest, char *source, int size)
> then the code will look like this
> {
>   char *temp;
>
>   temp = (char *) malloc(size);
>   memcpy(temp, source, size);
>   memcpy(dest, temp, size);
>   free (temp);
> }

> If you don't like using malloc, there is another way.
> Test the value of the pointers to see which is greater.
> If SOURCE is greater then you can copy from the beginning of source
> to the beginning of dest 1 char at a time with no problem.
> If DEST is greater you need to copy from source to dest 1 char at 
> a time starting at the ends of the areas.

There is no *portable* way to determine whether one pointer is earlier
or later in memory than another; the ISO standard states that the result
of a comparison is undefined if the two pointers are not into the same
object.

Having said that, if we assume that no interrupt or similar problem will
occur when two pointers to different objects are compared, but instead
either "true" or "false" will be returned at random (this assumption is
true for some architectures and false for others), then the technique
described will work, because:

    If the source and data overlap, they must lie in the same object,
    and so the comparison is valid, or else the size argument is such
    that the copy is not from or to a single object, in which case the
    copy is unsafe (and memmove is undefined) anyway.

    If the source and data do not overlap, it doesn't matter which
    result the comparison gives, as either method of copying gives the
    same result.

This sort of thing is why memmove is in the standard separately from
memcpy.
-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive@x.co.uk          | Vision Park         | it will get its revenge.
Phone: +44 223 236 555 | Cambridge   CB4 4RZ |   - Henry Spencer
Fax:   +44 223 236 550 | United Kingdom      |
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: gcc and cc!
Date: 6 Nov 92 11:39:47 GMT
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

In article <1dctt2INNkbi@function.mps.ohio-state.edu>
ren@function.mps.ohio-state.edu (Liming Ren) writes:
>It seems to me that if we have two object file , say foo.o and bar.o,
>one is compiled with gcc and the other with cc, then we can't link them 
>together ....  Could some experts say more about this.

This is *extremely* implementation-dependent.

Every C compiler author must make decisions about the mapping from
C source code to machine concepts and instruction set.  For most
current machines, much of this mapping is obvious and straightforward,
so that two compiler authors, working completely independently, are
likely to come up with compatible schemes.

There are some notable exceptions:

	Whether string literals wind up in read-only storage.

	Stack frame layout (e.g., whether to waste a register on a
	frame pointer, and where arguments go).

	Structure arguments and return values.

	Variable argument lists (printf() et al).

	Alloca.  (Strictly speaking, this is not a `real' C function,
	but most implementations provide it anyway.)

	Object file formats, including symbol table formats.

If you can avoid any dependence on these---the last one is impossible
---you will usually be able to intermix different compiler objects.

In the specific case of GCC, GCC itself is typically compiled with,
and/or tries to work with, each vendor's default implementation.  This
tends to remove some of the above obstacles.  One that is likely to
remain, and to affect user code, is the one dealing with structures.
GCC provides a huge collection of special-purpose options, such as
`-fpcc-struct-return' and `-msoft-float', to help work around these.
-- 
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: champion@cch.coventry.ac.uk (Alun)
Subject: Re: Rounding floats to integers
Organization: Coventry University, Coventry, UK.
Date: Wed, 11 Nov 1992 12:22:03 GMT

In article <rfries.123@sceng.ub.com> rfries@sceng.ub.com (Robert Fries) writes:
~In article <92314.134711IA8@psuvm.psu.edu> IA8@psuvm.psu.edu (Alan R. Heyd) writes:
~
~>What I do now is add 0.5 to the float before it is converted to
~>an integer, for example:
~
~To round to NEAREST integer, you'd have to test if fractional part is less 
~than 0.5; if YES, drop fractional part, if NO, add 0.5, then drop fraction.
~You'd also get to choose what to do if fractional part is EXACTLY 0.5.

No !! If you add 0.5 to something with a fractional part of less than 0.5
you will still have the same "int" value.
But adding 0.5 is not general enough..

int round(float n)
{
    if(n < 0)
        return (int)(n - 0.5);    
    return (int)(n + 0.5);     // Doesn't the function do the cast automatically
}

I prefer this than using the math libraries where you have to test
if the fraction is greater or lesser than 0.5 then use ceil() or floor()
respectively. Not only that they return doubles so internal conversion
has to be done anyway.

    -Alun
    
-- 
A.Champion                |  That's an interesting point, in the sense of
(champion@uk.ac.cov.cck)  |    being very not interesting at all. - The Liar
Newsgroups: comp.lang.c
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Re: Help - What Is Wrong?
Followup-To: comp.programming
Organization: Clemson University, Clemson SC
Date: Fri, 13 Nov 1992 18:20:44 GMT

In article <138740001@hpcupt1.cup.hp.com> jamiller@hpcupt1.cup.hp.com (Jim Miller) writes:
>>comp.lang.c / mjs@hubcap.clemson.edu (M. J. Saltzman) 
>>
>>Presumably, "i != 5" is "less safe" because a failure of the initial
>>condition to satisfy i < 5 will not result in an infinite loop
>>(especially if the initializer "i = 0" is replaced by, say, "i = j + 1",
>>or if the initial i is passed as a parameter).  On the other hand,
>>this may not be the best kind of "safety" to have.
>>
>>In _The_Science_of_Programming_[1], David Gries argues that the guards
>>on loops should be as weak as possible, so that if the initial
>>condition is violated, the program will fail catastrophically (i.e.
>>with an infinite loop).  
>
>IMHO: yes and no.
>
>While unit testing, "i != 5" might be the better idea for the reasons stated,
>for *production* I'd choose "i < 5".  If the program can continue to limp
>along instead of crash/hang, the user may still be able to use it,
>they may be able to save their data, they may even be able to survive.
>
>[discussion of advantages of each form in various contexts deleted]

Of course, like any advice on *style*, this should be (and is, in the
book) prefaced with the clause, "All other things being equal, ..."
Which option is preferable depends a lot on the consequences of the
error that caused i to be > 5 in the first place.

There are situations where the error would not be severe and the
program could continue without causing major problems (I think these
would be real-time control systems), but there are many other
situations where the undetected error is the more dangerous outcome.
In record-keeping applications, such an error could cascade through
the system, causing a major problem.  In real-time systems, it might
be better for the system to fail, and/or return control to a human
operator, rather than to continue on an erroneous course.  Do you
follow comp.risks?

Also, as I pointed out in the discussion on comp.programming, I did
take the recommendation out of context.  The weak loop guard is also
a consequence of the program derivation method.  It has the advantage
in that context that its negation is strong, and proof of the loop 
postcondition is simplified.

I think designing *robust* programs (that fail gently or recover when
errors are detected) is not exactly the same as designing *correct*
programs.

>Ok, David Gries and I disagree. 
>So, an  expert  and I disagree.
>So, what else is new?  :-)

Well, all generalizations are false 8^), even those made by experts.

>
>   jim miller
>   jamiller@cup.hp.com
>   (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... )
>   Anything I say will be used against me ...
>   But my company doesn't know or approve or condone anything of mine here.


-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
From: wct@po.CWRU.Edu (William C. Thompson)
Newsgroups: comp.lang.c
Subject: Macros
Date: 7 Nov 1992 07:41:56 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: wct@po.CWRU.Edu (William C. Thompson)
NNTP-Posting-Host: slc5.ins.cwru.edu


I'm trying to write a macro that allocates memory for Rows double *,
and then allocating for Cols double.  Basically, A is a double **,
which points to a row of double *, which point to a buffer of doubles.
A[i][j] is then the jth element in the ith row.  But I'm having
trouble with this macro business.  I don't want to write a function
to do it.

ALL.H
-----
#define malloc2d(A,rows,cols); (
{
  int i;

  if (((A)=(double **)malloc(sizeof(double *)*(rows)))==NULL)
    printf("Allocation error!\n");
  for (i=0; i<(cols); i++)
    if (((A)[i]=(double *)malloc(sizeof(double)*(cols)))==NULL)
     printf("Allocation error!\n");
}
)

TEST PROGRAM
------------
#include <stdio.h>
#include <all.h>

double **A;
int i,j;

main()
{
  malloc2d(A,50,50);
  for (i=0; i<50; i++)
    for (j=0; j<50; j++)
      A[i][j]=1.0/(i+j+1.0);
  return 0;
}

It doesn't compile, though.  What gives?  E-mail responses, please...
-- 
"What do you mean Star Trek isn't real!?" - anonymous
Newsgroups: comp.lang.c
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: Reasons for using C vs. Fortran or vice/versa
Organization: Department of Chemistry, University of Toronto
Distribution: usa
Date: Fri, 13 Nov 1992 17:12:41 GMT

In article <1992Nov13.043250.28205@sbcs.sunysb.edu> rhorn@csws8.ic.sunysb.edu
(Robert Horn) writes:
>rons@hardy.u.washington.edu (Ronald Schoenberg) writes:
>>  Fortran arrays are column echelon for a
>>reason, and C arrays are row echelon slowing down matrix operations
>>relative to Fortran.     
>
>Wouldn't FORTRAN arrays actually be slower? consider the normal
>
>  for(index = 0; index < kRows; index++) {
>    for(jndex = 0; jndex < kColumns; jndex++) {
>      myArray[index][jndex] ...
>    }
>  }
>
>one normally accesses matrices in a row major fashion (index changes less
>often than jndex), so if your array is stored row major, and your cache is
>nice enough to bring in the words around what you need (since you may well
>access these as well), the time to access each element should be slightly
>faster with row major than column major (if you access like above (as does
>nearly everyone)).

     This is silly.  (I hope Robert and Ronald don't feel picked on; I
just selected this posting because it presents both (incorrect) positions
on this storage order question.)  Both C and Fortran SHOULD be equally
fast on array operations as long as you know what you're doing in
either language.  (C will actually be slower if you have good optimizers
in both compilers unless you hand-tune the C code carefully.  Again, I
can provide an example of this on request.)  The thing that both the C
and Fortran programmers who have posted to this thread seem to not
understand is that Fortran and C store their arrays differently:
Fortran stores arrays in column major order and C stores arrays row
major.  If you access the arrays in the appropriate order for each
language, there is NO difference between the two since in both cases you
can arrange to access memory sequentially.  Now go have a look at your
introductory linear algebra textbook.  If the book is reasonably
comprehensive, you will notice that every theorem comes in both
row-oriented and column-oriented versions.  Storage order therefore
doesn't matter either from a practical or from a theoretical standpoint
as long as you know what it is in whatever language you use.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca