HDTenEightyP/NetNews huggingface dataset:
From: ptran@envmsa.eas.asu.edu (Phi-Long Tran)
Subject: Re: While problem
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: Arizona State University, Tempe, AZ
Date: Wed, 22 Jul 1992 23:53:00 GMT

In article <92204.160015GNR100@psuvm.psu.edu>, GNR100@psuvm.psu.edu writes...

>   I'm having trouble with a whil loop in function I am writing to
>read a line from a fileby puttingeach character into an array, accesed by
>pionters, until the '\n' character is reached of EOF is reached.
>Trouble is, I keep getting an error message that the function needs an
>Lvalue (address) inside the while loop.  Any ideas as to the problem?
>The filename is a global variable, and that's why it isn't declared.

>char readline(char *string[])
>{
>  int i=0;
> 
>  while(((*string+i++=(char)getc(fname))!=EOF)
>      &&((*string+i++=(char)getc(fname))!='\n'));
>  return (*string+(i-1));
>}

     I commend your courage for even attempting to write this kind of
gobbledegook -- I don't think even B. Kernighan or D. Ritchie would even
try this stuff, let alone P.J.  Plauger.

     Here are my observations:

1) Function getc accepts a file pointer ("FILE *"), *NOT* a file name.  You
can find this out in *ANY* book on C -- just look for a description of the
routine.

2) You are doing too many things at once to even possibly debug reliably.
Do you really understand all those operators, their precedence, their
side-effects, etc. ad inifitum. et. al.

3) To read in a line of text, you do not need an array of pointers (that's
what "char *string[]" is and means).  You just need an array of characters
into which a file I/O routine will fill with the characters.

4) Why are you performing arithmetic operations on the left side of an
assignment statement?  Look in a C book on making assignments.

     If all you want to do is read in a string, then there are many
standard library functions you can call:  fgets, gets, fscanf, scanf ...
They are declared in the header file "stdio.h" that you include in a module
when you use them.

     #define MAX_INPUT_CHARS 132 /* Or some relevant value. */

     ...

     char szData[MAX_INPUT_CHARS];
     FILE *pfileInput;		   /* Pointer to a file for input. */

     ...

     if (fgets( szData, sizeof( szData ), pfileInput) == NULL)
     {
        /* An error occurred. */
     }

     Above all ... LOOK IT UP IN A C BOOK.  Only post when you have
EXHAUSTED your resources for information.  Have you looked this problem up?

---
Phi-Long Tran
ptran@asuvax.eas.asu.edu
Arizona State University
From: dbushong@wang.com (Dave Bushong)
Newsgroups: comp.lang.c
Subject: Re: Obfuscate C Code
Date: 21 Jul 92 19:20:28 GMT
Organization: Wang Labs, Lowell MA, USA

rich.friedman@matrix.sbs.com (Rich Friedman)  writes:

>mckain@enuxhb.eas.asu.edu (Mark E. McKain) writes:

>>>Kok G Sang writes:
>>>I really don't know where to post this question, but I need to know
>>>if there are any public domain/shareware/commercial programs that
>>>obfuscates C source code.

>>Purposely obfuscating C source code seems to be, in general, counter-
>>productive. However, I realize that obfuscated C code can be used to test
>>tools like C beautifiers and "lint".

>Unfortunately, depending upon the programmer, C source code can be well
>obfuscated long before an "obfuscating" program is used on it.

Some people call this "shrouding source code" so that they can
distribute source without making some clever algorithm known.
-- 
==========================================================================
Dave Bushong, KZ1O@K1UGM.MA         +    No .sig, no tattoo, 
Wang Laboratories, Inc.             +        no bald spot, no nothin!!
Internet: dbushong@wang.com         +-------------------------------------
Project leader, OCR Products        + (reserved for future expansion)
Newsgroups: comp.lang.c
From: card@sybus.com (James Card)
Subject: Re: converting C 'for' to PASCAL 'FOR'
Organization: Sybus Corporation, Largo, FL
Date: Wed, 29 Jul 1992 04:51:13 GMT

>>In article <1992Jul28.151937.247@falcon.navsses.navy.mil>, huynh@falcon writes:
>>I am interested in doing this using the #define statement.

In article <1992Jul28.220307.13267@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>No.  PLEASE don't do this.  It is a bad, vile thing to use the preprocessor
>to re-define the language to make it look like some other language.
>
>Trust me, you're better off using C's control structures as they stand.
>You're programs will be easier to understand, and you'll learn C a lot
>quicker if you don't try to pretend that it's Pascal.

Here, here!  I heartily agree with Dave Schaumann.  I knew a guy that did
this and found (later) that his programs were not very maintainable.  Not
only that, but no one else wanted them either!  The preprocessor is a
powerful thing, but it is so easy to misuse.

jC
-- 
  __/o___~_                 James Card (Firmware Engineer)
 (________|  Nothin' like   Sybus Corporation
   @    @    top down       2300 Tall Pines Dr. Suite 100
             weather...     Largo, Fl  34641  (813) 535-6999
From: murphy@npri6.npri.com (David P. Murphy)
Newsgroups: comp.lang.c
Subject: Re: About the 'F' in RTFM
Date: 27 Jul 92 15:15:52 GMT
Distribution: world
Organization: NPRI, Alexandria VA



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

ok
dpm
-- 
murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090

              When every one is dead the Great Game is finished.  Not before.
                              --- Hurree Babu, "Kim"
Newsgroups: comp.lang.c
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Pointers to freed memory
Date: 30 Jul 92 08:20:58 GMT
Organization: AND Software BV Rotterdam

In article <1992Jul29.205834.11308@hubcap.clemson.edu> mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
|I know that a pointer to freed memory should never be dereferenced, 
|but is it standard-conforming to assign or do arithmetic with such
|pointers?
|
|The application is a routine to free the elements of a circular list.
|Since I have a count of the elements, I can simply run a pair of pointers
|around the list, like so:
|
|	for ( p = head, i = 0;  i < n;  i++ ) {
|		q = p;
|		p = p->next;
|		free(q);
|	}
|
|The question comes up because on the last iteration, p->next points
|to the element freed in the first iteration.  Do I need to break the
|circle before I start the loop? Or am I just being paranoid after the 
|discussion of pointers to invalid array elements?

Erm, yes, I hate to say it, but you're getting paranoid ;-) 

As long as you do not dereference such a pointer (as you indicated
yourself,) everything is fine.  If pointer q contained a valid pointer
value _before_ the call to free(), it'll contain a valid pointer value
_after_ the call. In the last iteration, the value p->next points to
a location in memory where the first element of the list _would have
been_ if it weren't freed in the first iteration. And, again, if you
don't dereference that pointer value, everything is safe and sound.

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: HIgher problems at hand. HELP!
Date: Wed, 29 Jul 1992 16:30:26 GMT
Organization: D'Arcy Cain Consulting

Ross Ridge <ross@zooid.guild.org> writes:
>darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>>Except that the whole point is to prevent any warnings with full checking
>>turned on.  Putting the define after the include would cause warnings
>>when strstr was redefined. 
>If strstr() is declared in <string.h> then why are we redefining here?
>Wouldn't it already be in the standard library?

I have been slowly building up an entire standard library based on code
from the net and my own additions and modifications.  As part of this I
wrote my own string.h based on the ANSI standard.  Given that then I
am in effect the implementor and there is no standard library until I
compile it.  I also use parts of the project to add ANSI functionality
to systems that I support.  I generally find I can simply replace the
standard string.h with my own. (*)  Users can then add non-existent
functions (Usually strerror(3)).  In those cases it is in the header
but not the standard library.

>>Other than changing the language itself I don't believe there is a "right"
>>way to code strstr(3).
>What's wrong with "return (char *)s;"?

As I explained in previous posts the problem is more basic than that.  The
strstr function and others claim to return a pointer to non-const space
whereas in reality the pointer may very well be to const char.  A good
compiler that checks that sort of thing will warn you no matter what you
do in the function.  Everything you do (including simply ignoring the
warning message or turning them off) is just a kluge.  "define const"
is just my own kluge.

BTW this isn't true in C++ where you can do:

const char *strstr(const char *s, const char *wanted);
char *strstr(char *s, const char *wanted);

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Hungarian notation
Date: 22 Jul 92 23:14:55 GMT
Organization: negligable

I think a lot of the strength behind the Hungarian fetishists is
the fact that the MS Windows calls and variables all use Hungarian
notation.

The concept of Hungarian (i.e. put a short prefix on variable names
so that some sort of typing information is available when reading code
without requiring the user to flip back four-or-five pages to find
out whether "index" is an int or a char) is good, as long as it is
consistantly used.  I have seen some people imply that if you use
Hungarian notation you can't make variable names that say what it
is used for (a file position vs. some other type of int was mentioned).
That is a ridiculous argument -- nFilePos vs nStudentCount -- there,
it's been done.  And using Hungarian yet!

The problems I have with it are 

	1) people who want to use overly long "type" prefixes
		(e.g. "char charC, charInitial, charInput")  This
		just causes a whole bunch of typing!

	2) the lack of any one central reference standard, I have
		seen both "n" and "i" used as the prefix for integers,
		there has been talk of "sz" and "strz", and some old
		fashioned folks using "pc" for pointer to arrays of
		characters (strings).  Some people like to add "a"
		for array (e.g. anChapters for an array of integer
		chapter numbers).  It seems that any group of 
		programers, once they agree to use the concept have
		to further agree on just what set of prefixes they
		will be using!  (Of course, if there were a central
		reference, it would probably be Simyoni (sp?), and
		he favors the longer prefixes I already griped about
		in item #1! :)



		-Richard Hartman
		hartman@uLogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Disco isn't dead...			...it's just in witness protection!

Newsgroups: comp.lang.c
From: markkj@mullian.ee.mu.OZ.AU (Mark Johnston)
Subject: Variable arguments & macros...
Summary: How???
Keywords: macros, varargs
Organisation: Computer Science Department, Melbourne University, Australia
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 22 Jul 1992 02:19:05 GMT


    I'm wondering if anyone has any really devious ways of writing macros
so that variable arguments can be used.  The problem is that I have a function
that does error handling for a program, and it takes variable arguments:

int writeErrorMsg(int quit, char *file, int line, char *format, ...)
{
 /* ... */
}


    The macros are:

#define error(x) writeErrorMsg(0, __FILE__, __LINE__, x)
#define fatal(x) writeErrorMsg(1, __FILE__, __LINE__, x)


    Last but not least, I'm using the functions in the following way:

	error("The error code is %1d.", errCode);


    I'm using the macros so that the code is more readable, without the
preprocessor thingys there to obstruct the view.  The compiler is gcc, 
on a sun-4/75 (ie no problems with badly written compilers...)


	
	Any brilliant ideas?

	Thanks in advance...

		Mark Johnston.


================================================================================
                                              | markkj@marvin.its.unimelb.edu.au
Real programmers get it right the first time: | markkj@munagin.ee.mu.oz.au
                                              | markkj@krang.vis.citri.edu.au
    #include "/dev/tty"                       | markkj@mundil.cs.mu.oz.au
                                              |    mkj@tauon.ph.unimelb.edu.au
================================================================================
From: mozart@coos.dartmouth.edu
Newsgroups: comp.lang.c
Date: 18 Jul 92 20:39 MDT
Subject: Re: About the 'F' in RTFM
Nf-ID: #R:1992Jul17.202448.19848@wyvern.tw:-789306601:1992Jul18.163941.24358@dartvax.d:853162565:001:1265
Nf-From: coos.dartmouth.edu!mozart    Jul 18 20:39:00 1992


In <1992Jul17.202448.19848@wyvern.twuug.com> Joe Wright 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.

>-- 
>Joe Wright  alpha@wyvern.twuug.com    

(names withheld to protect the innocent :-)

There was once when a user had overheard a conversation in the Consultants'
Office here at the college, and came in wanting to know what this "RTFM"
thing they kept saying meant.

The head consultant thought fast and, handing the user a Microsoft Word
manual, said "Read the manual..."

The user said "Ohhhhh...a Microsoft thing!" and left happy.

Sighs of relief were exchanged all 'round.

-Sting

------------------------------------------------------------------------
Michael J. Fromberger
Consultant, Computer Resource Center
Dartmouth College, Hanover, NH
CRC: (603) 646-2626  HOME: (603) 643-5716
Sting@Dartmouth.EDU / mozart@coos.dartmouth.edu / 69224f@d1
  all requests granted - all grants requested
------------------------------------------------------------------------
--
------------------------------------------------------------------------
Michael J. Fromberger
Consultant, Computer Resource Center
Dartmouth College, Hanover, NH

Newsgroups: comp.lang.c
From: au141@cleveland.Freenet.Edu (Amber M. Spillers)
Subject: Re: Borland 3.1 ext. mem. capabilities?
Reply-To: au141@cleveland.Freenet.Edu (Amber M. Spillers)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Thu, 23 Jul 92 00:41:09 GMT


In a previous article, rdw@vax5.cit.cornell.edu () says:

>Dear fellow MS-DOS C programmers:
>
>     I am a Microsoft C 6.0 user thinking of switching to Borland C++ 3.1.  My
>main concern is accessing about 7 megs of extended memory past the 640K limit
>imposed by DOS.  I am already using large linked lists rather than
>multidimensional arrays to conserve memory, but I still need more.  Does anyone
>know about Borland's Extended Memory Interface or its VROOM features?  For
>example, will it let me access this much memory?  Is there a counterpart in

  I do belive vroom only applies to program overlays which would not
help you with you large amount of data *too* much.

>Borland C++ to Microsoft's _huge pointers?  Can I mix memory models with
>Borland (i.e. _huge pointers with a large memory model compilation)?  Any other
>thoughts on or reactions to Borland's product would be much appreciated.

   yes you can mix pointers ane memory models.

>
   what is looks like you will need is a dos extender if you are sure
you want to address that much memory.  unfortunately theyre are many
drawbacks to them.  the first is expense, most cost a few hundred just
to start off with and often you need to pay for a licence of each
running copy(of your compiled program)!  they also have a tendency to
cause system compatibility problems, at least they did nefore the DMPI
rules came out.  maybe things have changed but I am willing to bet there
is still a lot of NON-DPMI stuff out there.
   I have a hard time "suggesting" one concidering these drawbacks.  are
you sure it would not be easier to swap some stuff to disk occasionally?
or possibly use some form of compression in memory?  or even possibly
escape dos and run it under unix or VMS?  
   as you can see I am not all for dos extenders, and yes I do use one.
but for use there really as no other way (we had to address memory above
1 GB because of a multibus II crate).


-- 
"Stay Sane Inside Insanity" -- The Rocky Horror Picture Show
sysop of the Rocky Horror Picture Show BBS 1-618-529-5999 24Hrs
USR Dual Standard ** programming support ** NON-Etherealized

Newsgroups: comp.lang.c
From: mv@dasc.nl (Martin Viet)
Subject: Re: About the 'F' in RTFM
Organization: Data Sciences B.V.
Date: Tue, 21 Jul 1992 10:55:40 GMT

 [ stuff deleted ]

>NOT from _me_.
>EVERYBODY knows about the meaning of the 'F' in RTMF - _SO_ _WHAT_ !!!

 [ more stuff from humorless German (pleonasm?) deleted ]


>cu
>	apo

fu
	Martin Viet
#include <stddisclaimer.h>       This might not be the view of my employer.
Newsgroups: comp.lang.c
From: dockhorn@fzi.de (Patrick Dockhorn)
Subject: Summary: Macro with variable number of arguments
Followup-To: poster
Keywords: macro arguments variable number summary
Reply-To: dockhorn@fzi.de
Organization: Forschungszentrum Informatik (FZI), Karlsruhe, Germany
Date: Sat, 25 Jul 1992 14:02:04 GMT

Two weeks ago I posted a request to solve the problem 
of having a macro with a variable number of arguments.
In fact, the question was a little bit more detailed:
I wanted a macro that allowed me to pass parameters to it
in the way you call the printf - function.
I knew of the solution with the double parenthesis, i.e.

#define DEBUG_OUT (x) printf x

and calling the macro with e.g.

DEBUG_OUT(("File %s, Line %d : Fatal error !",__FILE__,__LINE__));


My special problem was how to use this trick to write the error text to
stderr instead of stdout. The straight-forward solution to this was given
to me by Leo (leo@ine.philips.nl) and Jos (jos@and.nl):

#define DEBUG_OUT(x) fprintf x

and then use it (again) with the argument list enclosed in double parentheses:

DEBUG_OUT((stderr,
	   "file %s, line %d - error %d occured.",
           __FILE__,__LINE__,error_code));


The other solutions all mentioned the use of a variable arg list function;
they all looked more or less like this:

#define DEBUG_OUT(x) eprintf x

#include <stdarg.h>	/* vararg.h on some systems */
#include <stdio.h>

/* just like printf, but to stderr */
int eprintf(const char *format, ...) 
{
 va_list args;
 int retval;

 va_start(args, format);
 retval = vfprintf(stderr, format, args);
 va_end(args);
 return retval;
}


I'd like to thank the following net.people for their
suggestions; they have been very helpful:

Fergus Henderson 	(fjh@munta.cs.mu.OZ.AU),
Gene Ressler 		(ressler@cs.cornell.edu),
Michael Gordon		(mfg@castle.edinburgh.ac.uk),
Patrick Schaaf 		(bof@midget.saar.de)
Raymond Chen		(raymondc@microsoft.com)
Jutta Degener 		(jutta@cs.tu-berlin.de)


	Patsch

-- 
Patrick Dockhorn	       Forschungszentrum Informatik, Karlsruhe/Germany.
INTERNET: dockhorn@fzi.de      There are two rules for success in life:
BITNET  : ukew@dkauni2.bitnet  Rule 1:  Don't tell people everything you know.
From: scs@adam.mit.edu (Steve Summit)
Subject: Re: Matt Dillon's DICE (Amiga C) and rand() function
Organization: none, at the moment
Date: Thu, 30 Jul 1992 20:09:46 GMT

[This is a lightly edited version of an article I posted a few
minutes ago; readers with especially nimble fingers may have seen
the previous one before I canceled it.]

In article <1992Jul29.163704.26489@proxxi.se>, elias@proxxi.se (Elias M}rtensson (proxxi)) writes:
> CADS_COLE@GALLUA.BITNET (Kevin Cole; Washington DC) writes:
>> According to Matt Dillon's DICE documents, I can limit the range of values
>> returned by rand() if I define the variable RAND_MAX to something other than
>> the default.
>
> I have never used DICE but it looks like RAND_MAX is an extern int.
> Try this instead:
> 
> extern int RAND_MAX;
> 	RAND_MAX = 1023;

No.  Kevin Cole was (literally!) on drugs when he wrote the above
about "defin[ing] the variable RAND_MAX to something other than
the default."  RAND_MAX is a macro, provided by the system (in
<stdlib.h>, on ANSI systems) which tells you the range of values
which rand() *will* give you.  It is not possible to reprogram
rand()'s range on-the-fly, nor meaningful to redefine RAND_MAX.

To get integral random numbers with a different range, the
modulus operator is typically used:

	rand() % n

gives random numbers in the range 1..n-1 .  (Note that this
technique is slightly inaccurate, and works well only if RAND_MAX
is much greater than, or an exact multiple of, n).

One legitimate use of RAND_MAX is generating random floating-
point numbers; for example,

	rand() / (double)(RAND_MAX - 1)

should give randomly distributed numbers over the range 0..1 .
(This method, too, is potentially imperfect; it will have
problems if RAND_MAX is not exactly representable as a double
value).

					Steve Summit
					scs@adam.mit.edu
Newsgroups: comp.lang.c
From: somerville@BAEPV3.NCSU.EDU (SOMERVILLE)
Subject: Re: While problem
Reply-To: somerville@BAEPV3.NCSU.EDU (SOMERVILLE)
Organization: North Carolina State University
Date: Mon, 27 Jul 1992 13:20:59 GMT

In article <131@nixeidsc.sni.ie>, bsullivn@nixeidsc.sni.ie (Bryan O'Sullivan) writes:
>
>
>GNR100@psuvm.psu.edu writes:

 [Stuff Deleted]

>: char readline(char *string[])
>: {
>:   int i=0;
>: 
>:   while(((*string+i++=(char)getc(fname))!=EOF)
>:       &&((*string+i++=(char)getc(fname))!='\n'));
>:   return (*string+(i-1));
>: }
>
>Well, first off, your call to getc will bomb if you ever get the rest of
>the program running.  Getc(3) takes a FILE pointer, not a file name, as
>argument.  Also, (no flame intended) you're making the classic new C
>programmer mistake of trying to do too many "neat" things inside your
>while loop, which is part of the reason why it isn't working.
>
>
>char readline(char string[])
>{
>	int i;
>
>	for (i = 0; (string[i] = getc(fp)) != EOF; i++) {
>		if (string[i] == '\n') {
>			break;
>		}
>	}
>	return &string[i-1];
>}
>
>
>[Rest Deleted]

Although this may work, I do not believe it is portable.
If string is a char *, then

    (string[i] = getc( fp )) != EOF  

could be a problem.  getc() returns an int and EOF is a 
negative value.  You do not know if the implementation treats chars 
as signed or unsigned.  If you want to test for EOF, use an int to
hold the return value from getc():

  int c;
  .
  .
  ... (c = getc( fp )) != EOF ...
  .
  .
     string[i] = c;


I could certainly be wrong -- perhaps someone with a copy of the
standard could comment on this. 

--
Garth Somerville
somerville@bae.ncsu.edu
Newsgroups: comp.lang.c