HDTenEightyP/NetNews huggingface dataset:
From: jle9162@venus.tamu.edu (ECKHARDT, JASON LEE)
Newsgroups: comp.lang.c
Subject: Re: 386 C Compilers
Date: 24 Jul 92 16:41:00 GMT
Distribution: na
Organization: Texas A&M University, Academic Computing Services
News-Software: VAX/VMS VNEWS 1.41

In article <ntfgb4u@Unify.Com>, dbrus.Unify.Com.tsv@unify.uucp (Tim Vannaman) writes...
>Does anyone recommend a C compiler that will compile in full 386 mode and 
>extend DOS above the 1 MEG limit?  Let me know.
>  THANX!
> 
>--
>Tim Vannaman, Premium Technical Support Engineer   Phone: (916) 928-6433
>Unify Corporation, Sacramento, California    Fax: (916) 928-6403
>tsv@unify.Com  or  {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!tsv

  Yes, if you your on a DOS platform, the Watcom C/386 8.0 is excellent.
It has a 386 DOS extender which allows your code to run in 386 protected
mode and of course access all available memory in a flat model fashion.
  I believe the cost is down to $650 or so from most mail order dealers.
From: kgs@cunixb.cc.columbia.edu
Newsgroups: comp.lang.c
Date: 18 Jul 92 09:57 MDT
Subject: Re: Any C code to obfuscate C code?
Nf-ID: #R:711328600snx@rcsl.demon.co.uk:-1314384550:1992Jul18.055740.708@news.columb:-1287664640:001:603
Nf-From: cunixb.cc.columbia.edu!kgs    Jul 18 09:57:00 1992


In article <711328600snx@rcsl.demon.co.uk> tim@rcsl.demon.co.uk (Tim Frost) writes:
>>I need to know if there are any public domain/shareware/commercial 
>>programs that obfuscates C source code. 
>
>There is a commercial program called C Shroud available from Gimpel Software
>who are on (215) 584-4261.  I do not have current pricing info.  Gimpel
>are the people who produce the excellent PC-Lint package.

I'd like to thank to all those who responded to my question. I have been
able to find, thanks to Martin Dunstan, source code to opqcp.c, a C
obfuscator in ftp.uu.net in comp.sources.misc.

Kok
From: craigh@cserver.plexus.com (Craig Heilman)
Newsgroups: comp.lang.c
Subject: good C cross-reference generator (not cxref) - where???
Keywords: cxref
Date: 27 Jul 92 20:55:29 GMT
Organization: Plexus Corp. -- Neenah Wisconsin


Subject line says it all.  I can't use cxref since I can't overide it's
choice of C pre-processor and the one it uses is not ANSI (and my code
is).  Is there any way to override cxref's defaults (man page was worthless)
or is there a better tool (free) out there?  I have gcc (2.1) but couldn't
find any cross-reference option in it's documentation (p.s. is there a special
utility "MakeInfo" needed to make reading the documentation easier? and where
do I get it?).

Thanks,
	Craig
--
*                           * "I just found out that the brain is like a   *
* Craig A. Heilman          * computer.  If that's true, then there really *
* craigh@cserver.plexus.com * aren't any stupid people.  Just people       *
*                           * running DOS." - VH1's Stand Up Spotlight     *
From: fischer@iesd.auc.dk (Lars Peter Fischer)
Newsgroups: comp.lang.c
Subject: Re: About the 'F' in RTFM
Date: 18 Jul 92 21:46:53 GMT
Organization: Mathematics and Computer Science, Aalborg University


Fine.

RTF jargon file.

/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things.  -- Calvin
Newsgroups: comp.lang.c
From: jes@grendel.demon.co.uk (Jim Segrave)
Subject: Re: converting C 'for' to PASCAL 'FOR'
Distribution: world
Organization: None
Date: Wed, 29 Jul 1992 13:28:59 +0000


In article <1992Jul28.151937.247@falcon.navsses.navy.mil> huynh@falcon.navsses.navy.mil writes:

> Hello,
> 
> I am curious if there is a way to translate the "C" for(i,start,last,incr)
> statement into the PASCAL FOR i = start to last DO (* incr = 1 *).
> I am interested in doing this using the #define statement.
> Has anyone done this? Help is much appreciated.
> 
> Here is an example of how the "C" 'for' statement is translate into FORTRAN
> 'DO':
> #define DO(i,start,last,incr) for((i)=(start);(i)<=(last);(i)+=(incr))
I think the Pascal FOR doesn't do the assignment if the condition is not met:
so
    i := 2;
    FOR i := 3 TO 0 ...
would never assign 3 to i, since the loop wouldn't execute.
I could be wrong, it's been years since I read the User Manual and
Report (which may not be ANSI/ISO anyway).
> 
> Thanks in advance.
> 
> Nhan H. Huynh, PASCAL 's structure 's best
> Science and Engineering Aprrentice, Naval Base, Philadelphia PA.
> 
> 
--
Jim Segrave (Segrave Software Services)     jes@grendel.demon.co.uk

Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: About the 'F' in RTFM
Organization: Texas Instruments Inc
Date: Tue, 28 Jul 1992 17:13:56 GMT

In <5963@npri6.npri.com> murphy@npri6.npri.com (David P. Murphy) writes:



>>>> Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
>>>> The 'F' does not relate to any known adjective for Manual.
>>>> 'Read The Manual' should suffice.
>>>>
>>>>alpha@wyvern.twuug.com

> >>The usual interpretation of the F is an accurate description of the quality
> >>of most UNIX manuals.  The correct response to `RTFM' is "I *did* read it,
> >>and it didn't answer the question I wanted answered."
> >>
> >>jlg@cochiti.lanl.gov (Jim Giles)

>  >At which point, of course, you reach up, pull down the appropriate 
>  >manual, open it up, drop it in front of them and point.  They then
>  >say, "Oh," and walk away looking sheeplike.
>  >
>  >mccall@mksol.dseg.ti.com (fred j mccall 575-3539)

>close, fred, but no cigar.  assuming for the sake of argument
>that the information really _is_ in the manual, then the novice
>says "Oh.  dammit, why isn't there an INDEX in this manual??"

At which point you fix him with the look reserved for killing small,
brain-dead rodents and either point out that the commands are in
alphabetical order or hand him the book describing the layout of the
manuals. 

-- 
"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.
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Variable length records
Date: 30 Jul 92 00:22:28 GMT
Organization: University of Helsinki

barmar@think.com (Barry Margolin) writes:
>But if you want the contents of the array portion to be copied in such
>contexts, neither does your char* version.  

True enough, but at least it is apparent from the declaration.

On the other hand, perhaps this thread is getting a bit too long: if you
want strict conformance and portability, use a separately allocated
array, if you prefer a little bit of convenience, use the others.  And
the '[1]' version (see earlier posts) may even have both qualities (I'm
not quite certain).

--
Lars.Wirzenius@helsinki.fi
From: smr@iti.org (Stephen Riehm)
Newsgroups: comp.lang.c
Subject: Re: About the 'F' in RTFM
Date: 22 Jul 92 13:47:05 GMT

bbobak@violet.waterloo.edu (Brad Bobak) writes:

>In article <1992Jul21.005916.22447@organpipe.uug.arizona.edu>, dave@cs.arizona.edu (Dave Schaumann) writes:
>> 
>> A frank discussion of the f-word below; those of tender constitutions may
>> wish to press 'n' now.  Also, the discussion is related to C only by the
>> most tenuous of relations...
>> 
>> In article <1992Jul20.162942.14863@mic.ucla.edu>, stephen@eggneb (Stephen Schimpf) writes:
>> >> > |Proposed change to 'standard' practice.  'RTFM' is now 'RTM'.
>> >> > |The 'F' does not relate to any known adjective for Manual.
>> >> > |'Read The Manual' should suffice.
>> >> > 
>> >> > fabulous? famous? fancy? fantastic? fascinating? fateful? favourable?
>> >> > fine? forgiving? forgotten? formidable? funky? funny? ;-)
>> >>
>> >>fucking?

just so that we continue to get sidetracked ( from exactly what, I am
not sure ), I have a question to the poser of this question....

			WHY?????

since in 99.999999....% of the cases that the 'word' RTFM is used, it
is used as a word in it self ( who actually says "read the <insert
favourite F word here> manual" these days??? )... So all in all you are asking us
to all change our habits ( which we have worked so hard on developing )
and to lose _ONE_ letter. And since you have now seen so many equally
valid options for the F, it should be no trouble to explain ( to the
un-enlightened ) what the meaning of the acronym really is.

While we at spelling ( refer to Jargon file at this point ), I have
always spelt kluge as 'kludge', since in the Australian dialect,
kludge is a little easier to pronounce ( or someone in our past
stuffed up the pronunciation and we all followed like sheep ). Having
enlightened myself by reading Steven Levy's book "Hackers" recently, I
now know for sure that kludge is actually kluge and that the
definition is something like:

Kluge: An inelegantly constructed piece of hardware ( this was taken
from MIT AI labs in the 50's when hardware was more predominant than
software ) which seems to defy logic by actually working properly.

Well, it was an honour and a privilege to help waste a little more
bandwidth in this particular newsgroup, and as a footnote, I still
spell kluge as kludge, because I am a stubborn bastard who likes my
bad bad habits :-)

catchya

-----------------------------------------------------------------
Stephen Riehm				   smr@pki-nbg.philips.de
not in any way talking on behalf of:
Philips Kommunikations Industrie	  Phone: +49 911 526 2975
8500 Nuremberg, Germany			    Fax: +49 911 526 2095
I come from the land down under, where women glow and men chunder
From: ptran@envmsa.eas.asu.edu
Newsgroups: comp.lang.c
Date: 18 Jul 92 12:36 MDT
Subject: Re: How to implement a bit array?
Nf-ID: #R:1992Jul17.143744.12549@tamsun.ta:-1367172306:18JUL199201363630@envmsa.eas.asu:1546792954:001:937
Nf-From: envmsa.eas.asu.edu!ptran    Jul 18 12:36:00 1992


In article <1992Jul17.143744.12549@tamsun.tamu.edu>, 
tpradeep@cs.tamu.edu (Pradeep K Tapadiya) writes...

>In my project I need an array of 30000 elements which have {0,1} values only.
>I guesss a good way to implement this is such that each element takes just
>one bit. Can someone suggest me a good struct/union implementation for
>a bit array.
> 
>Ideally I should be able to do the following operations:
> 
>     whatever.whatever...[13467] = 1; // or 0
> 
>     if( whatever.whatever...[i] ) {  code }
> 
>However the following is acceptable ( worst case)
> 
>   BitSet(Array, 13467, 1);
> 
>   if( IsBitSet(Array, i) ) { code }
> 
> [etc.]

     C does not have "bits" available as a type that you can use.  If you
are not pressed for space (13467 as an index?), use an array of char.  I
believe that characters are the narrowest type you can have an arrow of.

---
Phi-Long Tran
ptran@envmsa.eas.asu.edu
Arizona State University
From: richk@grebyn.com
Newsgroups: comp.lang.c
Date: 17 Jul 92 20:53 MDT
Subject: Re: (Help) dynamic use of sprintf ?
Nf-ID: #R:brself.711345285@hal:945470687:1992Jul17.165343.13102@grebyn.co:800124447:001:1713
Nf-From: grebyn.com!richk    Jul 17 20:53:00 1992


In article <brself.711345285@hal> brself@hal.gnu.ai.mit.edu (Ben Self) writes:
>
>Could anyone please help me with a C programming dilemma that has plagued me
>for ages.
>
>Often when formatting strings or converting numerics to alphas, sprintf ()
>appears as an extremely attractive possibility.  Unfortunately, it does not
>fit well with dynamic allocation nor is it easily safe guarded from 
>segmentation faults and bus errors.
>
>I have tried many methods in the past, but am not happy with any yet tried.
>
>Some of these include:
>
>     . using the return value of fprintf () to a file pointer attached
>       to /dev/null with the same arg format that I pass to sprintf ()
>
>     . determining the size of integers by log10 or (in the event I
>       don't want to link to the math library) dividing by 10 until
>       it becomes fractional.
>
>     . writing my own subset of sprintf () which takes care of this
>       problem [far more work than it is worth].
>
>
>We must sell -- any serious offer will be accepted :-)
>
>Thanks in advance.

	Yes... Anyone with a good answer please post!

	When I was struck with this problem I #define'd a symbol giving
the number of characters I expected the sprintf to produce, plus a few
extra, based on visual inspection of the format string.  I placed the
#define close to it's use, and I put a big note on the definition
saying how I picked the number, and imploring anyone who changed the
format to re-count and change the #define.  In short, I just tried to
make it obvious to any reader that this was a tricky area.

-- 
Richard Krehbiel                                 richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
From: wkaufman@us.oracle.com
Newsgroups: comp.lang.c
Date: 18 Jul 92 20:46 MDT
Subject: Re: Handling signals (was:  trappin
Nf-ID: #N:1992Jul18.164658.14314@oracle.us:2096584799:001:1278
Nf-From: us.oracle.com!wkaufman    Jul 18 20:46:00 1992


In article <1992Jul17.141248.4837@mdd.comm.mot.com> mitchell@mdd.comm.mot.com (Bill Mitchell) writes:
] 
] Looking in PJP's "The Standard C Library", chapter 9, I see that he goes on
] at some length about syncronization and other problems which can occur in
] handling signals.  In part, he says:
] 
]   The occurence of a signal introduces a second thread of control within
]   a program.  That raises all sorts of issues about syncronization and
]   reliable operation.  The C Standard promises little in either regard.
]   C programs have been handling signals since the earliest days of the
]   language.  Nevertheless, a portable program can safely take very few
]   actions within a signal handler.

    OK, so this just says that the signal handler should be *very*
careful about touching global variables, right?  Doing nothing,
exit()'ing, or writing to a variable that the main program only reads
from (or vice versa)--these should all be safe, right?

    Is there anything else that would be guaranteed to work?

                                           -- Bill K.

Bill Kaufman,          | "Hush my darling / Be still my darling /
Corporate Lackey       |  The lion's on the phone,..."
wkaufman@us.oracle.com |              -- "The Guitar", They Might Be Giants
From: pauls@truevision.com
Newsgroups: comp.lang.c
Date: 18 Jul 92 16:54 MDT
Subject: Re: Hungarian notation
Nf-ID: #R:mechp05.uucp:35240001:1992Jul18.125442.5470@truevision:-320400983:001:1248
Nf-From: truevision.com!pauls    Jul 18 16:54:00 1992


Why don't you forget about Hungarian notation (trying to do type checking by
hand), and just select the identifier in question, hold down the middle mouse
button and read the pop-up dialog box that tells you what the identifier
(or other symbol) is all about?
    What type it is (if it is a variable or a type)
    Its current value (if it is a variable, and the program is running)
    Notes you or past programmers may have typed in about that identifier
    ....
If you want the dialog box to hang around after you release the mouse
button, just release the middle mouse button outside of the dialog box.

Why not quit wasting net bandwidth arguing about whether Hungarian notation
is useful, and just implement a programming environment that includes features
like the ones I made up in the previous paragraph?
I don't imagine too many people will be interested in Hungarian notation once
they have such a programming environment.
People who like Hungarian notation won't bother with it any more.
People who don't like Hungarian notation who't have to see it any more.
People who don't really care about Hungarian notation can read interesting
articles in comp.lang.c again.

Paul Scherf
pauls@truevision.com
Truevision Inc., Indianapolis, IN
From: debeaupr@napier.uwaterloo.ca (David Beaupre)
Newsgroups: comp.lang.c
Subject: C Source Beautifier
Date: 31 Jul 92 15:08:26 GMT
Organization: University of Waterloo

Sorry if this a repeat question:

Can someone please recommend to me a good C code beautifier
something that when give a C source file as input will go through
it wrapping all lines great than a certain length, making all functon
calls look standard etc.

If you have one in mind, could you please email a possible ftp address
for the executable ( and source if possible).

Thank you.
Dave

-- 
=====================================================================
David Beaupre					| "Think HONK iF
University of Waterloo				|    you are a 
debeaupr@descartes.waterloo.edu			|   telepath!"
debeaupr@descartes.uwaterloo.ca			|
CompuServe-> 71201,1176				|
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.lang.c
Subject: Re: My view of variable naming conventions (was: Hungarian...)
Date: 27 Jul 92 15:32:46 GMT

I admit I should just let this thread die, but I wanted to make a few
more comments.

dave@cs.arizona.edu (Dave Schaumann) writes:

>Absolutely.  There's even a name for this: "encapsulation".  To get more
>practical: use structs to group related variables, even if makes the actual
>code a bit longer.  Ultimately, you'll find it makes maintenence easier when
>related variables are related by a physical structure in the code (as opposed
>to use and unreliable or nonexistant documentation).

You still have to name the fields of your structure somehow.

>Programming in the large is as much about managing complexity as it is about
>solving the problem at hand.  Any competant programmer can solve all the 
>problems that comprise a large program *in isolation*.  And the key to
>managing complexity lies in careful use of encapsulation and abstraction.

>If you're having problems remembering the type of a variable, you're
>probably better off rethinking you're program's abstractions, rather
>than adopting some bizarre naming convention that's harder to remember
>how to use than it is to remember the types of your variables

Obviously, nobody would use a naming convention that is difficult to
remember.

I spent several years writing and maintaining a medium size piece of
code (300,000 lines or so) with various other programmers.  Adopting a
(group-wide) naming convention let me go into my own code years later
and immediately figure out what was going on.  It let me immediately
know the return type and argument types of a function even if I hadn't
written code that called that function in a year.

Probably those types should have been obvious.  When I was in school,
they taught me about encapsulation and abstraction, and I apply them.
However, it doesn't do much good to say ``rethink your abstractions''
when you're dealing with a large amount of code which you don't have
time to rewrite.  Especially when that code was written when you were
young and stupid (for me, that's generally about six months in the
past at any given time), or, worse, by other people.  In fact, I
rewrote as much code as possible; but the pressures and options in the
``real world'' have nothing at all to do with what I was taught in
school.

And I won't even describe the advantages of an entire group of
programmers using an agreed naming convention, since they will be
obvious upon reflection.

I'm not at all trying to suggest that everybody should use a naming
convention; people should use whatever works best for them.  But,
frankly, I find assertions that people who use naming conventions are
bad programmers both naive and irritating.
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
``It takes a man months and months to reconcile himself to a new hat.  And
  just when you're preparing to send it to the jumble sale, he says, `That's
  rather a nice hat you've got on, where did you get it?' ''
Newsgroups: comp.lang.c
From: spt@sgtech.sgtech.com (Steve Thorn)
Newsgroups: comp.lang.c
Subject: overlaying variables: the right way?
Date: 28 Jul 92 13:58:23 GMT


Someone asked me the other day how to write a function that is passed a string
and a 'type' integer, and return a value in a known memory location which is
of the 'type' asked for.  eg. convert(&string, type, &value_buffer).  This is
what I came up with, and I'm wondering if there's a better/prettier way.

#define INT_T    0
#define CHAR_T   1
#define STRING_T 2

void convert(string, type, value_buffer)
  char *string;
  char type;
  void *value_buffer;
{
  switch (type) {
    case INT_T:
      sscanf(string, "%d", value_buffer);
      break;
    case CHAR_T:
      sscanf(string, "%c", value_buffer);
      break;
    default:
    case STRING_T:
      strcpy(value_buffer, string);
      break;
  }
}

void main()
{
  char value[256];

  convert("34.56", INT_T, value);
  printf("Integer is %d\n", *(int *)value);
  convert("34.56", CHAR_T, value);
  printf("Char is %c\n", *(char *)value);
  convert("34.56", STRING_T, value);
  printf("String is %s\n", value);
}

Any ideas?

-steve


Steve Thorn                         spt@sgtech.com
Star Gate Technologies, Inc.        ...!uunet!abvax!sgtech!spt
29300 Aurora Rd, Solon, OH  44139         216-349-1860
From: griff@ccwf.cc.utexas.edu (yo'man)
Newsgroups: comp.lang.c
Subject: fuzzy logic. . .
Date: 29 Jul 92 19:57:41 GMT
Reply-To: griff@ccwf.cc.utexas.edu (yo'man)
Organization: The University of Texas at Austin, Austin TX
Originator: griff@huey.cc.utexas.edu


I'm looking for some fuzzy logic share/freeware for c to be run on a 68030 MVME147 board.
anyone know of any libraries out there?


-andrew
Applied Research Laboratories
University of Texas at Austin

Newsgroups: comp.lang.c
From: shaun@octel.com (Ralph Neutrino)
Subject: Re: Q: returning function pointers
Organization: Octel Communications Inc., Milpitas Ca.
Date: Fri, 24 Jul 1992 21:26:10 GMT

In article <1992Jul20.204737.1279@cs.cornell.edu> ressler@cs.cornell.edu (Gene Ressler) writes:
>In article <1992Jul20.195626.12620@cs.tu-berlin.de> jutta@opal.cs.tu-berlin.de (Jutta Degener) writes:
>>gabara@eueh30.tuwien.ac.at (Andrej Gabara) writes:
>>> I'd like to know whether it is possible that a function can return a function
>>> of its own type (so that it can return itself).
>>
>>It is impossible to describe the type of your function in C.
>
>True.  Recursive function types can't be written in C, but
>a recursive struct def and be pressed into service:

[code example deleted (but it surfaces again below)]

If you've been properly conditioned, the line 

  f("Hello").f("world.").f("This").f("is").f("silly.\n");

can appear to be very close to the desired 

  f("Hello")("world.")("This")("is")("silly.\n");
 
by doing

  struct fool { struct fool (*fnord)(); } fnord(s)
  char *s; 
  { 
    struct fool fs; printf("%s ", s); fs.fnord = fnord; return fs;
  }
  
  main()
  {
    fnord("Hello").fnord("world. ").fnord("This").fnord("is").fnord("silly.\n");
  }


I'm sure you can use this technique to bag the babes*.

I am only beginning to appreciate the wackiness that pointers to functions can
lend a program.

@Man

* Or boys, as the case may be.

-- 
shaun@octel.com  ||  G is for Jesus

"We will buy Iron Camels from GoMotion
   Unlimited in Santa Clara California."
Newsgroups: comp.lang.c