HDTenEightyP/NetNews huggingface dataset:
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Determining variable type at run-time (followup q.)
Date: 1 Oct 92 18:39:23 GMT
Organization: negligable

In article <1992Oct1.045215.20906@news.iastate.edu> djaschbr@iastate.edu (David J Aschbrenner) writes:
>
>	struct foo {
>		char type; /* type = 0 for char, 1 for int, 2 for char *, etc*/
>		void *value; /* this is a ptr to the actual value */
>	};
>
>	main()	{
>		struct foo x;
>		char	c = 'a';
>		int	i = 456;
>		char	*str = "this is a string";
>
>		x.type = 0;
>		x.value = (void *)&c;
>		OutPut(x);
>
>		x.type = 1;
>		x.value = (void *)&i;
>		OutPut(x);
>
>		x.type = 2;
>		x.value = (void *)str;
>		OutPut(x);
>
>		exit(0);
>	}

The union idea works, but you have to test the type every time
you want to use the value, which could become a pain very quickly
depending upon how much use this thing gets.  

If you really want to implement a "variable type" type, you should
explore C++.  You could encapsulate all of these tests and use
the value of 'x' transparently (sort of...).

I still want to know why you need to do this thing....

As far as your example goes -- it will work as far as it goes,
but since i, c and str are allocated on the stack when that 
routine exits your pointers will be off in never-never land.
(well, ok, main doesn't exit, but if you assign pointers
into the fields of x from a subroutine that refer to variables
on the stack of those routines you'll have problems....)

Safer would be:
	
		x.type = 0;
		x.value = malloc(sizeof(char));
		*x.value = c;
		OutPut(x);

		x.type = 1;
		x.value = malloc(sizeof(int));
		*x.value = i;
		OutPut(x);

		x.type = 2;
		x.value = malloc(strlen(str));
		strcpy(x.value, str);
		OutPut(x);


Of course you would have to remember to realloc() whenever
setting new values, and free() before leaving a routine if
a struct foo is used as a local var in a subroutine.....

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
And the men who hold high places	|
must be the ones who start		|	-Richard Hartman	
to mold a new reality			|	hartman@uLogic.COM
closer to the heart!			|

Newsgroups: comp.lang.c,comp.lang.c++,comp.os.msdos.programmer
From: swalter@nyx.cs.du.edu (DreamWeaver)
Subject: Re: [Stack Overflow] How do I find cause using Turbo Debugger?
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Sat, 3 Oct 92 16:57:10 GMT


> DOS does not automagically increase the programs' stack like 
> UNIX does. The stack you get at runtime is the stack you live 
> with.

Very true.  Borland compilers default to a 4K stack ... which may not
necessarily be enough (like the man said, it depends on your application,
the number of recursive calls you make, the number (i.e. space) of local
variables in your routines (not statics, automatics), and the depth your
routines go.

Another alternative is to _not_ set the "standard stack frame" flag in the
compiler/options ... as that saves a bit of space by not allocating stack
space for functions that have no parameters and no local variables.  The
only drawback to that method is that the Debug/Call Stack option (i.e.,
the debugger) can no longer "see" the function.

-Scotty

Newsgroups: comp.lang.c
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Subject: Re: Untyped pointer arithmetic
Organization: The Johns Hopkins University CS Department
Date: Thu, 1 Oct 1992 22:49:17 GMT

In article <1992Oct1.224734.5517@blaze.cs.jhu.edu> wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:
>In article <018yRB2w165w@quest.UUCP> srhqla!quest!kdq writes:
>>wilson@gauss.cs.jhu.edu (Dwight Wilson) writes:
>>> In article <14813@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O
>>> >So it is syntactically legal to do
>>> >	void *p, *q;
>>> >	ptrdiff_t d;
>>> >	d = (char*)q - (char*)p;
>>> 
>>> Not quite.  This is only a legal pointer operatin if p and q point
>>> to members of the same array, or either is the address of the first 
>>> element past the the end of an the array.  
>>
>>Do you really mean legal, or do you mean meaningful?
>>
>
>If p and q are not members of the same array (with the above

Oops.  That should read, "... are not pointers to members of
the same array..."

-Dwight

Newsgroups: comp.lang.c,comp.lang.c++
From: jzawodn@bgsu.edu (jeremy zawodny)
Subject: Help needed in performing word-wrap in C/C++...
Organization: Bowling Green State Univ.
Distribution: na
Date: Sat, 3 Oct 1992 20:12:25 GMT


I am currently writing an simple text editor in C++.  I'm using Borland
C++ 2.0 and need suggestions on how to include word-wrap.  The
characters are being read from the input stream one by one via getche()
into a character array...

char chars[MAX_CHARS]
char in_character
.
.
.
in_character = getche();
.
.
.

After each keypress, the character is checked to make sure it isn't a
special character that I've predefined in my program (escape key, help
key, etc.).  I need a small function to check at see if it is at the right
end of the input window and in the middle of a word.  If so, them word
wrap should take place.

Any suggestions on the code for word wrap?  

Thanks,

Jeremy Zawodny

----
Bowling Green State University                         Computer Science Major
jzawodn@andy.bgsu.edu
From: mustafa@seas.smu.edu (Mustafa Kocaturk)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Summary: Return NULL if realloc fails
Keywords: realloc return NULL pointer
Date: 4 Oct 92 16:55:30 GMT
Organization: SMU School Of Engineering and Applied Science

In article <366@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:

>	3. If you cannot allocate new memory do NOT free the old

I agree.

>		and return the original pointer.
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is non-standard. NULL is returned if realloc fails.

Regards,
-- 
Mustafa KOCATURK  mustafa@seas.smu.edu   Electrical Engineering Department
Home:(214)706-5954  Work:(214)692-2541   SMU Box 753190, Dallas, TX 75275-3190
From: walduck@mpr.ca (Andrew Walduck)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 2 Oct 92 18:47:24 GMT
Article-I.D.: mprgate.1992Oct2.184724.2758
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada

In article <1992Oct2.080610.28537@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>What's wrong with
>
>	void *realloc( void *p, unsigned s ) {
>	  void *new_p ;
>	  if( (new_p=malloc(s)) == NULL ) {
>	    errno = ENOMEM ; return p ;
>	    }
>	  bcopy(p,new_p,min(s,SIZE(p))) ;
>	  free(p) ; return new_p ;
>	  }
>
>	/* SIZE(p) is some system-dependant thing that */
>	/* gives the size of the chunk of memory p points to */
>
>A nice, simple interface, that works on your system, and does something
>reasonable besides failing when there's no new memory to copy to.  The
>error condition is still detected and signalled to the user, but IMHO
>in a much more robust way than returning NULL.
>
>Sure, this code still `fails', but it's much easier for the user to
>ignore that failure when it's convenient to do so.
>
>-- 
>Dave Schaumann			dave@cs.arizona.edu

What's wrong?? Lots...

If I get a pointer back from realloc it had better point to a block
of at least as many bytes as I've requested...

Yours doesn't do that in the error case. (Go see ANSI for the
"Complete and Utter" specification)

Andrew Walduck


-- 
Andrew Walduck, MPR Canada, walduck@mprgate.mpr.ca
-------------------------------------------------------------------------------
(I hope someone will flatter me by using this as a .sig quote...)
 -- Reid Kneeland
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: problem with "#include file.c"
Date: 29 Sep 92 23:23:24 GMT
Organization: negligable

Let the linker do it:

	cc -c module1.c -o module1.o
	cc -c module2.c -o module2.o
	cc module1.o module2.o -o program

Frequently the first two can be done w/o the "-o module.o" part.

Sounds like you're almost ready to learn about "make" :)


			-Richard Hartman
			hartman@uLogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I think.  I think I am.  Therefore ... I *am*!  (I think....)

Xref: sparky comp.lang.c:14239 comp.lang.c++:14274 sci.math.num-analysis:2865
From: books@fsunuc.physics.fsu.edu (Roger Books)
Subject: Re: What is RPG ???
Organization: FSU nuclear physics
Date: Fri, 2 Oct 92 12:30:03 GMT

In article <1992Oct2.015817.183@wsuhub.uc.twsu.edu> ckcheng@wsuhub.uc.twsu.edu writes:

>     Hey, does anybody heard of RPG (language or system?, NOT role playing 
game>) ?  Can anyone talk about it in this category or open a new category ?

Report Program Generater

I think the name says it all (it better, I know nothing about it and have
only seen it taught at Vo-Tech centers.)

Roger
books@fsunuc.physics.fsu.edu
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Microsoft C 7.0 Problem
Organization: SoftQuad Inc., Toronto, Canada
Date: Sat, 26 Sep 92 05:08:50 GMT

I'm astonished to see Karl Heuer (karl@ima.isc.com) write:
> The appropriate convention is that *object-like* macros should be all-caps,
> but function-like macros should be lowercase.  There's no reason for the
> user to know or care whether getchar() is a macro.

It is somewhat reasonable to use lower case for *safe* function-like
macros -- that is, those which do not read an argument more than once.
However, coding

	#define max(p,q) ((p)>(q)? (p): (q))	/* bad style - should be MAX */

is an open invitation to bugs (namely the infamous max(*p++,*q++) and such).
Upper case should be considered obligatory for these.

In addition, if getchar() was known to be a function, then

	int (*fp)() = getchar;

would be safe.  In ANSI C this *is* safe, because a getchar() function is
guaranteed to be provided as well even if there is a getchar() macro, but
not so in classic C.  This argues weakly that the convention of using upper
case for *all* macro names is a good one.
-- 
Mark Brader			"It's simply a matter of style, and while there
SoftQuad Inc., Toronto		 are many wrong styles, there really isn't any
utzoo!sq!msb, msb@sq.com	 one right style."	-- Ray Butterworth

This article is in the public domain.
Newsgroups: comp.lang.c
From: silvia@rcf.rsmas.miami.edu
Subject: Re: What is RPG ???
Reply-To: silvia@rcf.rsmas.miami.edu
Organization: RSMAS
Date: Fri, 2 Oct 92 22:14:37 GMT

In article <1992Oct2.015817.183@wsuhub.uc.twsu.edu>, ckcheng@wsuhub.uc.twsu.edu writes:
>     Hey, does anybody heard of RPG (language or system?, NOT role playing game
>) ?  Can anyone talk about it in this category or open a new category ?
RPG stands for Report Program Generator. It is usually found on minis and
mainframes. It is a language that requires inline coding. A real headache.



          Manolo
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: how do you use getpass() correctly
Date: 2 Oct 92 17:33:50 GMT
Article-I.D.: ulogic.370
Organization: negligable

In article <14839@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>By the way, if you are only going to read one password, why copy the
>answer?  Just do
>
>	char *the_only_password;
>
>	... the_only_password = getpass("Enter Password: "));

Because we have no guarantee that the pointer returned by getpass()
is to memory which will retain the data.  It is most likely that this
is a pointer to a static array declared w/in getpass(), but we don't
*know* that and shouldn't assume.  The safest thing to do with ANY
function returning a const char * is to COPY whatever it returns
as soon as possible to memory that we control.

Of course if you are going to use it once only, there is no need
for this e.g.:

	if (!strcmp(myPassword, getpass("Enter Password: ")))
		printf("you're in!\n");
	else
		printf("bogus, dude!\n");



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lovely to see you again my friend,		|
walk along with me to the next bend.		|	-Richard Hartman	
Tell us what you've seen			|	hartman@uLogic.COM
in far away forgotten lands,			|
Where embers have turned back to sand.		|
Xref: sparky comp.lang.c:14370 comp.lang.fortran:3806
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Mathematical Function Parser
From: huber@vax2.gac.edu (Tom Huber)
Date: Thu, 1 Oct 1992 13:41:12 GMT
Organization: Gustavus Adolphus College

Does anyone have a subroutine that will parse and evaluate a 
mathematical function.  I would like to incorporate into an existing program 
a subroutine which will accept a mathematical function as a string (such as '
exp(-a*x)*cos(b*x)' ) and will evaluate it for a given x value (or 
preferably multiple x values).  This would be used to plot user defined 
functions without linking them in separately.  The program I am using is in 
Microsoft Quick-C, but a standard FORTRAN or C function would work fine.  
THANKS.

 
-------------------
    Tom Huber                      Internet:  huber@gac.edu
    Physics Department             BITNET:    huber@gacvax1.bitnet
    Gustavus Adolphus College
    St. Peter, MN 56082 USA        Phone:     (507)933-7036
Newsgroups: comp.lang.c
From: hollasch@kpc.com (Steve Hollasch)
Subject: Re: ++i = i++ ?
Summary: In this context, yes.
Organization: Kubota Pacific Computer, Inc.
Date: Mon, 28 Sep 1992 18:41:40 GMT

In article <1992Sep28.162405.29567@fzi.de> fzi.de writes:
| I wanted to use the statement: 
|        
|        for (i = 0; i < Count, ++i)
|        { /*any correct c codes*/}
| 
| Then I made a typo by writting down "i++" instead of "++i" ...
| 
| The result: both of them are functioning (offer the same result)!
| 
| Someone there could enlighten me on this?

    I'll assume that you made a typo here and really meant to say

        for (i=0; i < Count; ++i)
                           ^ A comma here is a syntax error.

    The third expression here can be either "++i" or "i++".  This is
equivalent to the following while loops:

        i = 0;                           i = 0;
        while (i < Count)                while (i < Count)
        {   <statement list>;            {   <statement list>;
            ++i;                             i++;
        }                                }

    So really the only difference is the statement "++i" and the statement
"i++".  Both of these statements are throwaway expression statements, useful
only for their side effects.  For example, the statement

        frotz;        // Let's say frotz is an integer.

is a valid statement in C.  'frotz' is implicitely compared with 0, and then
the result (true or false) is discarded.  The net effect of this statement is
nil, and you could delete this statement or add 50 more like it without
any difference in execution (a smart compiler would delete these statements
anyway).  Note that the above statement has no side effects.

    The statements "++i" and "i++", however, do have side effects - namely,
the variable 'i' is incremented.  When the statement "++i" is evaluated,
'i' is incremented, the expression result is set true iff 'i' is now
non-zero, and the result is thrown away.  When the statement "i++" is
evaluated, the expression result is set true iff 'i' is currently non-zero,
_then_ 'i' is incremented, and then the result is thrown away anyway.  So
either way, the result of the implied comparison with zero is thrown away,
and the only effect is that 'i' gets incremented.

______________________________________________________________________________
Steve Hollasch                                   Kubota Pacific Computer, Inc.
hollasch@kpc.com                                 Santa Clara, California
Newsgroups: comp.lang.c
From: jsteele@netcom.com (John Steele)
Subject: Re: Curses to write to stderr, possible?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 6 Oct 1992 16:28:17 GMT

In <1992Oct6.034638.29275@oucsace.cs.ohiou.edu> tswingle@oucsace.cs.ohiou.edu (Tom Swingle) writes:

>In article <375@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>>Yeah, my suggestion has a portability problem -- anywhere that stdin
>>and stdout are macros instead of FILE * variables you've got problems.
>>
>>On the other hand freopen() only solves half the problem, redirecting
>>stdout to where you want.  The other half, RESTORING it afterwards, has
>>no portable solution that I am aware of.  Or even a common one.  At least
>>my suggestion works where the stdin & stdout are variables.  Does anyone
>>know how to "reconnect" stdin/stdout to their original sources after
>>haveing been freopened()?

>Would there be any problem with using memcpy instead of assignments?  I got
>the following program to work, and our system does #define stdin, stdout, and
>stderr rather than declare them as variables:

I'm not sure of problems this could cause on different platforms, but to
answer Richard's question:

See the dup(), dup2(), freopen() and fileno() functions.  This is the standard
way of redirecting and restoring standard file handles (again taken from
MSC Quick Help):

#include <stdio.h>
#include <conio.h>
#include <io.h>
#include <process.h>

void main( int argc, char **argv )
{
    FILE *ftmp;
    int htmp;

    /* Duplicate handle of stdin. Save the original to restore later. */
    htmp = dup( fileno( stdin ) );

    /* Process each command line argument. */
    while( *(++argv) != NULL )
    {
        /* Original stdin used for getch. */
        printf( "Press any key to display file: %s\n", *argv );
        getch();

        /* Reassign stdin to input file. */
        ftmp = freopen( *argv, "rb", stdin );

        if( (ftmp == NULL) || (htmp == -1 ) )
        {
            dup2( htmp, fileno( stdin ) );
            perror( "Can't reassign standard input" );
            exit( 1 );
        }

        /* Spawn MORE, which will receive open input file as its standard
         * input. MORE can be the DOS MORE or the sample program MORE.C.
         */
        spawnlp( P_WAIT, "MORE", "MORE", NULL );

        /* Reassign stdin back to original so that we can use the
         * original stdin to get a key.
         */
        dup2( htmp, fileno( stdin ) );
    }
    exit( 0 );
}


John
-- 
#include <disclaimer.h>			/* route all flames to /dev/null  */
/**************************************************************************/
/*   Systems Analyst      | John Steele     email: jsteele@netcom.com     */
/* Video Business Systems |                                               */
/*   1-800-255-3088       |    Most people spell COBOLSUX incorrectly...  */
/**************************************************************************/
Newsgroups: comp.lang.c
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Subject: Re: Is there is (pascal) WITH equivalent in C?
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Thu, 1 Oct 92 16:04:05 GMT

In article <1992Oct1.114517.3937@rz.uni-karlsruhe.de> ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke) writes:
>jos@and.nl (Jos Horsmeier) writes:
>> 
>> May I strongly suggest _not_ to use such macros, they're obfuscating 
>> the code. Just imagine what would happen if other structs happen to
>> have elements with the same names (bar and baz.) IMHO the WITH construct
>> in Pascal is silly, it just saves a couple of keystrokes, ... 
>
>That's just not true. Most non-optimising compilers would generate better
>and faster code from a WITH construct than from the corresponding construct
>without WITH.
>They would calculate the base address of the referenced RECORD variable
>only once and then add the corresponding offset of a RECORD component
>each time such a component would be accessed.
>If you don't use WITHs such a compiler would repeat the base address
>calculation for each variable construct that accesses RECORD components.
>Therefore a construct like
>
>  WITH a.b.c DO x := y + z;
>
>is always better than writing
>
>  a.b.c.x := a.b.c.y + a.b.c.z;
>

Well, I always thought the WITH construct in Pascal was prone to programmer 
errors, but...

I often do the following hand optimization in C:

  abc_ptr = &a.b.c;
  abc_ptr->x = abc_ptr->y + abc_ptr->z;

However, a good optimization pass should do this for you.  I only resort
to it because I'm stuck using Sun's bundled C compiler, and having full
debugging turned on, which precludes optimizing :-(

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 2 Oct 92 17:50:22 GMT
Article-I.D.: alice.23784
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Oct2.080610.28537@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:

> Sure, this code still `fails', but it's much easier for the user to
> ignore that failure when it's convenient to do so.

Some people consider that a disadvantage.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c,comp.lang.c++,comp.os.msdos.programmer
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: [Stack Overflow] How do I find cause using Turbo Debugger?
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Mon, 5 Oct 1992 16:23:37 GMT

In article <1992Oct3.165710.29483@mnemosyne.cs.du.edu> swalter@nyx.cs.du.edu (DreamWeaver) writes:
>
>> DOS does not automagically increase the programs' stack like 
>> UNIX does. The stack you get at runtime is the stack you live 
>> with.
>
>Very true.  Borland compilers default to a 4K stack ... which may not
>necessarily be enough (like the man said, it depends on your application,
>the number of recursive calls you make, the number (i.e. space) of local
>variables in your routines (not statics, automatics), and the depth your
>routines go.

	The stack is located at the top of the data segment.  Static data is
at the bottom, and in small data models, the heap grows upward from the top of
the static data.  You will not get a stack overflow unless you have stack
checking turned on and the stack collides with the heap or with the static
data.
	Explicitly setting the stack size determines the minimum amount
available.  If you also set the heap size, the data segment will be sized
appropriately, so you won't have as much total space available.  But the 4K
default "size" doesn't prevent your program from using more space if it's
available.
	-- Pete
Newsgroups: comp.lang.c
From: "hans friedrich steffani" <GM08@DKAUNI2.BITNET>
Subject: Re: Challenge to gurus... typecasting
Organization: University of Karlsruhe, Germany
Date: Fri, 2 Oct 1992 11:42:16 GMT

> From: robasky@tortoise.cis.ohio-state.edu (Kimberly Robasky)
> I've been reading the postings, and so far nothing has surprised me.  This,
> however, has me baffled.  Can anyone see what is wrong with the following
> code?  I have to assume from the nature of the crash that its a typecasting
> problem.
>
> Kim
>
> -------------------------------------------------------
> #include <stdio.h>
> #include <alloc.h>
>
> typedef float matrix_4x4[4][4];
>
> matrix_4x4 *make_W_dot(matrix_4x4 *t1, float *t3, int tot_links);
>
> main()
> {
>   int tot_links=1;
>   matrix_4x4 t1[1], *t6;
>   float t3[1];
>
>   *t1[0][0] =     1;  *t1[0][1] = 0;  *t1[0][2] =    0;  *t1[0][3] = 0;
>   *t1[1][0] =     0;  *t1[1][1] = 1;  *t1[1][2] =    0;  *t1[1][3] = 0;
>   *t1[2][0] =     0;  *t1[2][1] = 0;  *t1[2][2] =    1;  *t1[2][3] = 0;
>   *t1[3][0] =     0;  *t1[3][1] = 0;  *t1[3][2] =    0;  *t1[3][3] = 1;
why do you use *t1(0)(0) ? i think this takes t1(0)(0) and interpretes
the bits of this as a adress to wich is a 1 or 2 is wrote to. and this
would and as a problem. ( take the () as[] wich is difficulty for me
to type.

hans friedrich steffani
gm08@dkauni2.bitnet
uni karlsruhe