HDTenEightyP/NetNews huggingface dataset:
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: Re: Only C gurus allowed?!?!
Organization: National University of Singapore
Date: Thu, 10 Sep 1992 01:58:16 GMT

mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
: In <1992Sep9.051107.22938@nuscc.nus.sg> eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
: 
: >I posted something in this group to try to help someone out. 
: 
: >I got flaming mail to the effect that I was wrong, that my explanation
: >was garbage etc etc and that I shouldn't post in this group (to help
: >others) unless I'm very sure of the facts.
: 
: >Is there some kind of implicit censorship here? To the effect that only
: >C gurus are allowed to help others here?
: 
: No censorship that I know of, but if you were wrong, were you really
: "helping others"?

My examples were CORRECT. 

The whole purpose of the usenet is free and unrestricted flow of info.

Assume that I am wrong - though when I posted I believed I was right.
Then I should be treated like the newbie right?  - that's embarrisment
enough for me. Then Someone who knows better just correct me. 

I don't know - maybe I'm just too used to polite society ;-). 

jin meng
Newsgroups: comp.lang.c
From: mjn@pseudo.uucp (Murray Nesbitt)
Newsgroups: comp.lang.c
Subject: Re: primitive Question
Date: 9 Sep 92 08:42:07 GMT
Organization: Private system in Toronto, ON


wkaufman@us.oracle.com (William Kaufman) writes:
>In article <1992Sep4.141018.21826@fzi.de> xiong@fzi.de writes:
>] Has someone a "Convert_Integer_to_ASCII" C-function for a C-beginner?

>        char int_to_ascii(int i)
>        {
>            return((char)(i & 0x8F));
>        }

>[...]  In fact, you can just drop the function and assign the
>number to the character--even the cast is optional on an ANSI machine.

If the poster is looking for a way to convert an int value to a single
char, then there is no reason to use a function, like you say.  A
cast, however, has never been required: the value on the right side of
the assignment is converted to the type of the left side, ANSI or not.

But, if the poster is looking for the complement of atoi(), i.e., a
way to turn the integer value 100 into the character array "100", then
have a look at sprintf().

-- 
Murray
Newsgroups: comp.lang.c
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: How is NaN recognized?
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Fri, 11 Sep 1992 13:38:58 GMT

Two possibilities:

I recognize my Nan by looking for a crotchety old white haired lady who
accuses my wife of being a prostitute.  (not that I ever attempt to
recognize my Nan)

I recognize my nan by looking for a piece of flat bread that comes with my
Vindaloo.

:-)

-- 
Paul Tomblin - speaking from but not for GeoVision Systems Inc.
There are 2656 unread articles in 46 groups - don't you think you read too
much news?
From: cc100aa@xray.gatech.edu (Ray Spalding)
Newsgroups: comp.lang.c
Subject: Re: How to call procedure with a variable?!
Keywords: C VARIABLE PROCEDURE
Date: 10 Sep 92 19:36:37 GMT
Organization: Georgia Institute of Technology

In article <1992Sep10.143705.15262@galileo.cc.rochester.edu> eric@prodigal.psych.rochester.edu (Eric Hansen) writes:
>I'd like to be able to call a procedure based on the contents of a variable.
>For instance, if my variable  GOTOPROC is equal to "GetNewSearch(X,Y,Z)", then
>I'd like to somehow say GOTOPROC and have it perform the GetNewSearch
>routine.

You can just declare a variable of type pointer to function, and
assign (compatible) declared functions to it.  For example:

#include	<stdio.h>

int
getnewsearch(int x, int y, int z)
{
	return x + y + z;
}

int (*gotoproc)(int x, int y, int z);

int
main()
{
	int t;

	gotoproc = getnewsearch;
	t = gotoproc(1,2,3);
	printf("%d\n",t);
	return 0;
}
-- 
Ray Spalding, Office of Information Technology
Georgia Institute of Technology, Atlanta Georgia, 30332-0715
Internet: ray.spalding@oit.gatech.edu (NeXT Mail accepted)
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: Only C gurus allowed?!?!
Date: 9 Sep 1992 06:42:36 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Sep9.051107.22938@nuscc.nus.sg> eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
>Is there some kind of implicit censorship here? To the effect that only
>C gurus are allowed to help others here?

Censorship is when someone prevents you from posting.

>Does it matter whether I was right or wrong? There're plenty of fellas
>here willing to correct me if I'm wrong .... but please don't be
>offensive or [suggest] that I keep quiet.

If you post an incorrect answer, and someone else corrects you, how is the
original poster (who presumably knows less than either of you) supposed to
know which answer was the correct one?  Blatantly incorrect responses are
just going to confuse him more.

>Is is just this group or what? I don't get this kind of thing in the
>other groups I suscribe to. 

I've seen plenty of it in comp.unix.questions.  In general, it happens more
in the groups with lots of questions from newbies, rather than those used
for discussions among sophisticated users.  You need to be more careful
when responding in these groups.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: winfree@math.arizona.edu (Art Winfree)
Newsgroups: comp.lang.c
Subject: typedef and memory allocation
Date: 11 Sep 92 05:16:32 GMT
Distribution: usa
Organization: Mathematics Department, University of Arizona

typedef double vector[3]

main()
{
.
.
.
}

funky_func()
{
vector bigarray[100];
.
.
.
}

Question: Shouldn't a reasonable C compiler allocate enough
(3*100*sizeof(double)) memory for bigarray for use when funky_func()
is called? Evidently mine doesn't, since the code core dumps unless I
explicitly calloc in funky_func().  I know typedef itself doesn't
cause any allocation, but are typedef'd types, as above, supposed to
be sizeof'd and variables invoking them given appropriate memory, even
if included in local function array definitions?

thanks for any pointers -- Sandy

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             Jesus is my body bag...
###############################################################


Newsgroups: comp.lang.c
From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Subject: Best way to write part of a structure to a file?
Date: Tue, 8 Sep 1992 04:58:57 GMT
Organization: ISCA

I want to write only part of a structure to a file which contains the whole
structure, but other processes may occasionally want to write to other parts
of the structure and I want to minimize the chances the writes will conflict.
This may happen if I read the whole structure into memory, make a few changes,
then write the structure back to the file, but I figure the chances are much
less if I read the whole structure, make some changes, then write only the
changed portion (usually just a few bytes) back into the file, since the
chances another process is writing those same few bytes during the interval
between read and write is quite small (but if it happens it isn't a horrible
disaster)

Anyway, the hack I've currently settled on can be summed up in the following
code fragment, where the "store" call can be construed to take an argument
that is a pointer to a structname, and two further arguments that are an 
offset into the struct and the number of bytes in the struct to write.

main()
{
struct structname *X = 0;

...
store(s, &X->somefield, sizeof &X->somefield);	/* write only somefield */
...
store(s, &X->anarray[i], sizeof &X->anarray[i]);/* write part of an array */
...
store(s, X, sizeof *X);				/* write entire structure */
...
}

I've tested it and it works, but is this the best way of doing this?  I could
do something #define's and make this more clear in the future, but for now it
clearly shows (to me, at least) what I am doing, but I am worried as to its
portability.  The machine I'm working on right now is an HP 9000/710 running
HP-UX 8.07, and even when I set the compiler to give an error for referencing
a NULL pointer it doesn't complain about the "sizeof *X" etc., I assume they
are dereferenced at compile time.  Is this a fairly good assumption to make
about compilers in general?  I realize there must be some dumb ones out there.

If anyone can come up with a better/easier/clearer way of doing this, please
let me know.  Thanks!

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@isca.uiowa.edu       |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: Paranoia, side effects, and optimizing compilers
Date: 7 Sep 92 16:25:21 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle

In article <DAVIS.92Aug14120003@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu  (John E. Davis) writes:
/      unsigned char *p;   
/      while (1)
/        {  p = CLine->data + Point;
/           if (*p > ' ') break;
/           del();
/        }
/Would an optimizing compiler asssume that p will not change in the loop,
/evaluate it once and assume it is fixed in the loop?

A correct optimizer will assume that the function call to del():
o	Modifies all non-const global and static data.
o	Modifies all non-const data that is accessed through a pointer.

Thus, in your example, CLine->data is assumed to be trashed by the call to
del(), *unless* CLine->data is declared as 'const'.
Newsgroups: comp.lang.c
From: mjn@pseudo.uucp (Murray Nesbitt)
Subject: Re: string literal concatenation (was printf question)
Organization: Private system in Toronto, ON
Date: Sat, 5 Sep 1992 13:05:40 GMT
	<RICHARD.92Aug30153124@CLYDE.ttt.kth.se> <3361@dozo.and.nl>
	<1SEP199221241770@eql.caltech.edu> <MJN.92Sep3000652@pseudo.uucp>
	<26043@dog.ee.lbl.gov>


torek@horse.ee.lbl.gov (Chris Torek) writes:

>In article <1SEP199221241770@eql.caltech.edu> rankin@eql.caltech.edu
>(Pat Rankin) writes:
>>>Minor quibble:  string concatentation is performed by the compiler,
>>>not the preprocessor. ...

>In article <MJN.92Sep3000652@pseudo.uucp> mjn@pseudo.uucp
>(Murray Nesbitt) contends:
>>Concatenation of character string literals is performed during the
>>preprocessing phase of translation.

Note that I'm not saying that string literal concatenation must be
performed by "the preprocessor" or "the compiler".  In fact, in my
ANSI-conforming implementation, the C preprocessor ``cpp'' does not
perform string literal concatenation.  This isn't what I meant.

>Both are technically wrong; someone else (I forget who) got it right.
>Just for the record, the ANSI C standard (X3.159-1989) does not divide
>the task of compilation into `preprocessing' and `compilation' phases
>as such.  Rather, it lists *eight* separate phases.  Phase 4 might be
>called the `preprocessing' phase, but the standard does not do so.
>Syntactic and semantic analysis, which might be called `compilation',
>is phase 7.  String literal concatenation occurs in phase 6.

This is true, and I was a bit sloppy calling it a ``phase'', which I
meant in a broader sense than a particular one of the eight ANSI
translation phases.  But consider:

1) The description of string literal concatenation (i.e., ``phase 6'')
is pointed to by the entry "preprocessing concatenation" in the Index
(which is part of the Standard).  So, in a general, high-level sense
at least, the Standard would seem to imply that string literal
concatenation falls under the broad category of ``preprocessing''.

2) Plauger & Brodie (the secretary and chairman, respectively, of the
ANSI C Standards Committee), in their book _Standard C_, describe
string literal concatenation in a section entitled ``Preprocessing''.

Although there may not exist a particular reference to a clause in the
Standard which describes ``preprocessing'', there seems to be a clear
delineation of high-level phases (oops), in which string literal
concatenation would appear to fall under ``preprocessing''.

>Loosely speaking, then, concatenation occurs *between* preprocessing
>and compilation, not during either one.

Sorry, but ``phase 6'' isn't sexy enough.  To me, it is still
``preprocessing'' tokens in preparation for syntactic and semantic
translation in ``phase 7''.

>We now return you to your regular programming: megabytes of Unix- and
>MSDOS-specific news inappropriately directed to a generic C group. :-)

My apologies for discussing C in this group. :-)

-- 
Murray
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Newsgroups: comp.lang.c
Subject: Re: Problems with QSORT and function prototypes
Date: 15 Sep 92 12:32:25 GMT
Organization: The Johns Hopkins University CS Department

In article <1992Sep15.043445.3519@midway.uchicago.edu> pynq@midway.uchicago.edu writes:
>I have not been able to figure out how to pass a function pointer to the
>QSORT intrinsic function, when using function prototypes.
>
>Here is my program:
>
>#include <stdio.h>
>#include <stdlib.h>
>
>struct thing {
>        char *text;
>        int textlen;
>        } *things;
>
>my_cmp(struct thing *t1, struct thing *t2)
>{
>        /* Key is in col 39, length 12 */
>        return strncmp(t1 -> text + 38,t2 -> text + 38,12);
>}
>
>int_cmp(int *p1, int *p2) { return (*p1 - *p2); }
>
>main()
>{
>	/* (You get same results with either my_cmp or int_cmp) */
>        qsort(things,5,sizeof(struct thing),my_cmp);
>
>}

qsort() is declared as:

void qsort(void *base, size_t nmemb, size_t size,
           int (*compar)(const void *, const void *));

Your problem is being caused by the fourth argument, the comparison
function.  qsort's declaration means that the comparison function
should take two (void *) parameters and return an int.

Your functions expect two struct thing pointers or two int pointers.
You must rewrite them to take (void *) arguments (and cast them
internally).

-Dwight
Newsgroups: comp.lang.c
From: gt@rundart.demon.co.uk (Giles Todd)
Subject: Initializing Random Seeds 
Distribution: world
Organization: Rundart Limited
Date: Sat, 5 Sep 1992 01:56:07 +0000


In article <1992Sep4.173259.12437@maccs.dcss.mcmaster.ca> rickan@maccs.dcss.mcmaster.ca writes:

>Please excuse me if this is a FAQ, but is there a ANSI-compliant means
>of initializing a random seed which has a reasonably low probability
>of recurring? At the moment, I'm using srand in conjunction with
>time(&t). Unfortunately, on a fast machine, the time delay is often
>< 1 second, resulting in the production of the same random value.
>
>I've avoided this problem by use of a time delay, but I'm convinced
>that there must be a more elegant and efficient means of doing this.
>
>Any suggestions would be appreciated,

Ideally, you want some sort of non-deterministic event.  I have often
arranged things so that the seed comes from timing the interval between
two user supplied keystrokes (preferably with a timer resolution of much
less than 1 second).

Giles.
-- 
Giles Todd                      gt@rundart.demon.co.uk (Internet)
Voice: +44 925 33472            Data: +44 925 414696
Rundart Ltd, 5 Brentnall Close, Great Sankey, Warrington, WA5 1XN, UK
Xref: sparky comp.lang.c:13564 comp.lang.pascal:5345 comp.lang.misc:3036
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c,comp.lang.pascal,comp.lang.misc
Subject: Re: Opinions on case sensitivity in programming languages?
Date: 11 Sep 92 22:20:27 GMT
Article-I.D.: ima.1992Sep11.222027.4854
Organization: Interactive Systems, Cambridge, MA 02138-5302

>[Blah blah case wars blah blah]

Please, folks.  The originator of this thread asked for responses by *email*.
Let's wait until the summary arrives before continuing this.

>[What's the third English word with this property?]

And *this* is especially off-topic.  Please, don't start that discussion in
the technical groups.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.lang.c
From: ptran@envmsa.eas.asu.edu (Phi-Long Tran)
Subject: Re: INVERSE CHARACTORS?
News-Software: VAX/VMS VNEWS 1.4-b1  
Reply-To: ptran@asuvax.eas.asu.edu
Organization: Arizona State University, Tempe, AZ
Date: Fri, 11 Sep 1992 14:32:00 GMT

In article <15060003@hpdmd48.boi.hp.com>, 
slack@hpdmd48.boi.hp.com (David Slack) writes...

> ...  I am trying to learn to program in C, can anyone direct me to where
> I could find out how to print INVERSE charactors?  I am working on a menu
> screen in the HP-UNIX invironment and would like to be able to do it
> without using curses and in ANSI-C.  Any help is appreciated.

     I highly recommend that you try to stick with the Curses library.  It
is "mostly" compatible across several operating systems.  I know of
versions on UNIX, VMS, and MS-DOS.  A good book on Curses will help.  Using
Curses will be much simpler than attempting to write code from scratch to
handle different terminal types.

---
Phi-Long Tran
ptran@asuvax.eas.asu.edu
Arizona State University
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: sizeof()
Date: 10 Sep 92 08:43:52 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <Sep.9.14.38.29.1992.10548@turbo.bio.net>, will@turbo.bio.net (Will Nelson) writes:
> I've run into an incompatibility between Microsoft C 7.0
> and the unbundled ANSI C compiler (1.1) of SUN Microsystems.

Namely that sizeof SomeStruct is different.
Given that sizeof (int) may LEGITIMATELY vary between compilers,
is this really such a surprise?  (Hint: the structures being read
and written contain two ints, so there's a legitimate difference
for a start.)  You might be able to do something by using 'short'
(which is _likely_ to be 2 bytes on a PC and a SUN, but there are
no guarantees).  The next thing is the padding:

> struct Location {
>   char base_position[7];
>   int  operator_token;
> };

Even switching the order of the fields may not help.
And then these is the nasty problem that the SUN machines are big-endian
(worst thing I know about them) and the PCs are little-endian (best thing
I know about them).  That's the real show-stopper here.  At least you
haven't got any floating-point numbers to really stuff things up.

> If I look at what sizeof(Feature_Form_Buffer) produces, it comes out
> as 56 on the DOS side and 60 on the UNIX side.

That isn't the worst of your problems.

> Needless to say, this looks like a show-stopper.
> I've given up on trying to determine which is the "Correct" behavior,
> mainly because I don't have the ANSI C standards document.

They are _BOTH_ right.  From the ANSI standard you can deduce that
sizeof (int) >= sizeof (short) >= sizeof (char) == 1, but that's about
as much as you can rely on.  It would be perfectly legitimate for a C
compiler to decide that sizeof (int) == 10.

> What I want to know is, is there any way to get the UNIX acc compiler
> to give the same result as the DOS compiler?

No.  What you will have to do is write functions to convert a structure
to a sequence of bytes and to convert a sequence of bytes to a structure.
This will involve functions like

	void PutShort(unsigned short x)
	    {
		putc(x, Output);
		putc(x >> 8, Output);
	    }

	unsigned short GetShort()
	    {
		unsigned char a = getc(Input);
		unsigned char b = getc(Input);
		return (b << 8) | a;
	    }

> I would like to use
> the same code in both environments if at all possible.

Actually, nothing stops you using the same _code_ right now.
The only problem is if you want to use the same _binary files_.
Look up XDR in the SUN manuals.
-- 
You can lie with statistics ... but not to a statistician.
Newsgroups: comp.lang.c
From: thor@arrakis.denver.co.us (Robert B. Hood)
Subject: Re: EASY C
Organization: Bob's Programming Paradise, Lakewood, CO, USA
Date: Sat, 12 Sep 1992 03:56:54 GMT

In article <MJN.92Sep11004159@pseudo.uucp> mjn@pseudo.uucp (Murray Nesbitt) writes:
>
>faivre@cst02.segin.com (Denis Faivre) writes:
>
>>As far as I know, it consist in a set of #defines supposed to enhance
>>lisibility, coding and debugging of programs. For instance, braces are
>>#(re)defined as BEGIN and END, | as BOR (binary OR), || as OR, etc.
>>
>>Did somebody around experienced such a technique ? What do you think
>>about it ?
>
>If you want Pascal, you know where to find it.
>

I'm afraid I have to agree.  You certainly don't see Pascal programmers
converting their language-of-choice to resemble C, do you?

The preprocessor was not put there to obfuscate the language and get
some second-rate programmer who's paid by the hour more job security
(what are you, a lawyer? 8^).

Wait, what to you call 500 lawyers at the bottom of the ocean?

           1. An imminent patent on salt water
           2. Not enough
           3. The worst lawyer-tanker accident in American history
           4. Grease on the squeaky wheels of justice

(all I could think of off the top of my head)

Bob
-- 
Bob Hood    thor@arrakis.denver.co.us     H: 303-980-8392  W: 303-632-2180
---------------------------------------------------------------------------
               The post office never loses you junk mail...
From: mjn@pseudo.uucp (Murray Nesbitt)
Subject: Re: Help!!! Please Read this message!?!?!?!?!...
Organization: Private system in Toronto, ON
Date: Tue, 15 Sep 1992 06:30:15 GMT
	<1992Sep10.040600.27065@blaze.cs.jhu.edu>
	<MJN.92Sep11001608@pseudo.uucp>
	<1992Sep11.173009.12181@blaze.cs.jhu.edu>


wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:

>In article <MJN.92Sep11001608@pseudo.uucp> mjn@pseudo.uucp (Murray Nesbitt) writes:
>>
>>wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:
>>
>>>Huh?  "%f" specifies a double not a float.  If you think about the
>>>promotion rule you'll realize that specifying a float would be
>>>nonsensical since it is not possible for an argument to printf()
>>>to be passed as a float!  
>>
>>    printf( "%f...%s?\n", (float)f, "Huh?" );
>>
>>It's another matter whether you'd *want* to pass a float to printf(),
>>but it is possible.

> Without a prototype, it is impossible to prevent this promotion.

Actually, the promotion occurs even in the presence of a prototype for
``printf()'', because its prototype ends with an ellipsis.

-- 
Murray
Newsgroups: comp.lang.c