HDTenEightyP/NetNews huggingface dataset:
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Problem with Turbo-C: calculating with pointers 
Organization: SoftQuad Inc., Toronto, Canada
Date: Sun, 10 Jan 93 02:45:36 GMT

Reminder: it is neither necessary, nor preferred, nor desirable to
quote an ENTIRE article when posting a followup to it!!

> > char *pointer,*begin,*end;
> > long size;
> > 
> > size=71800;

> make this 71800L and it will work. This compiler like many others treats
> integer cosntants as 16-bit ints. 61800-65536 == 6264.

If so, it is a compiler bug.  Both K&R1 (page 180) and the ANSI/ISO
standard (section 3.1.3.2/6.1.3.2) specify that an integer constant
whose value doesn't fit in an int, but does fit in a long, has the
type long.  However, if there are really "many" compilers with this
bug, then using 71800L is a suitable workaround.

> > pointer=(char *)farmalloc(size*sizeof(char));
> > begin=pointer;
> > end=pointer+size;
> > printf("%p %p %ld",begin, end, end - begin);

If the results of converting the two pointers with %p had been given,
we would have been able to tell whether the above conjecture was right!
When posting a program in this situation, please include ALL relevant
output.

> > I would expect end-begin to return 71800. However it seems to return 6264.

Perhaps the implementation expresses the difference between two pointers
as an int rather than a long.  If so, and if objects can actually be large
enough to require a long to express the difference, this is stupidity
at least.  However, the only workaround I can suggest is, "get a better
compiler".

Note incidentally that printing the result of a pointer subtraction using
%ld is implementation-dependent.  The result actually could be an int, so
%ld could, for example, pick up an extra word from the stack.  Safer is
to use %ld and cast the result of the subtraction to long.

> Better still, don't do pointer arithmetic. It is a sure route to trouble.

This is followed immediately by a signature line of "Nil taurus excretum".
The two assertions seem to be in conflict.





I'd like to leave it at that, but for the benefit of the Latin-illiterate,
the signature quote is a mangled translation of "No bullshit".  I am,
therefore, saying that the suggestion to avoid pointer arithmetic is
exactly that.
-- 
Mark Brader					"Domine, defende nos
SoftQuad Inc., Toronto				 Contra hos motores bos!"
utzoo!sq!msb, msb@sq.com				    -- A. D. Godley

This article is in the public domain.
Newsgroups: comp.lang.c
From: zoltan@research.canon.oz.au (Zoltan Kocsi)
Subject: Re: extern: interesting case...
Originator: zoltan@radics
Organization: Canon Information Systems Research, Australia
Date: Fri, 8 Jan 1993 03:39:52 GMT

In article <bibhas.726341439@femto.engr.mun.ca> bibhas@pico.engr.mun.ca (Bibhas Bhattacharya) writes:

   When I declare:
   extern char line[];
   for the variable "line" which was defined in another file as:
   char line[80];
   everything works fine. But when I do:
   extern char *line;
   the program dumps core. I can't figure out the difference, especially when
   extern declaration is not supposed to reserve any memory or anything. When
   I looked up K&R, the correct declaration would be: extern char line[];.

   Can anyone please clarify the case.
   Thanks.
   Bibhas

Well, the K&R book tells you the truth. The declaration of an external object
tells the compiler the type and name of the object and the fact that the
actual memory allocation of the object is done in an other file.
That's why, when you write extern char x[] it declares an array of chars
named x. The actual size of the array is not required as
the compiler need not to allocate memory for it. This declaration
declares x as an array, that is, a memory location where _the_characters_in_
the_array_ can be found. On the other hand, if you declare 'extern char *y' it
tells the compiler that y is pointer ( a (probably) four-byte object ), the
pointed object is character and the memory for the _four_bytes_ is allocated
somewhere else. So when you write x[ 3 ], the compiler gets the address that
x itself symbolyses, adds 3 to it then accesses the byte at this address.
That's what you want. When you wrote y[ 3 ], the compiler got the address
meant by y, then read four bytes from this location (dereferenced the pointer)
handled this value as the start address of the array, added 3 to it and
accessed the byte at this address. Because at memory location y there was not
a pointer but some ASCII characters, the result address was rubbish, and you
were lucky that it pointed out of your memory segment causing the coredump.
Though the K&R book emphasyses the relationship between arrays and pointers,
it never tells that they are the same. In fact, you can write y = &my_char;
but you can never change the value of x ( being a symbolic constant ).
Also, &x == &(x[0]) == x but &y != &(y[0]) == y. 
There is a case in C where the two declarations identical:
If you have a function that has an input parameter of an array you can really
declare it either x[] or *y. It is because C never passes
arrays to functions, it _always_ passes the address of the array, that is
a pointer to the array. In that sense the declaration x[] is misleading as
the object you got from the caller is _a_pointer_ and not an array. (The
compiler internally transforms your x[] declaration to *x if it declares
an input parameter of a function.)

Zoltan.
	
-- 
Zoltan Kocsi <zoltan@research.canon.oz.au>
From: jshaw@hpb.hwc.ca
Newsgroups: comp.lang.c
Subject: computer.lang.c
Date: 10 Jan 93 16:26:04 EST
Organization: Health and Welfare, Canada

trying to learn how to use post command with no instructions
In case this message works I'll make it complete. I'm new to news.
I am learning to program in MS c with a professional development system on my
pc. Users in Alberta are a rare breed apparently because Ive been asking for
kindred uders via several pathwys for about 6 months . Most peoples are Turbo
C. The word above is users not uders. he he ! I'm also trying to use a few of
m Numerical Recipes in C and am having some of the beginners usual problems.Are
ther any kindred users out ther interested in answering a few questions? Please
respond directly to jshaw@hpb.hwc.ca thanks
post
  
the recipes for random generatoe fro A

post

cancel
exit
quit
cancel
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: const and pointers in ANSI C
Date: 12 Jan 1993 21:14:15 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1993Jan12.164949.15684@clsi.COM> shankha@clsi.COM
(Shankha Mitra) writes:
>	typedef int *int_pointer;
>	const int_pointer x;
>	int_pointer const y;

[In ANSI C, x and y wind up with the same type, despite the fact that if
the typedef is expanded as if it were a #define, they would wind up with
different types.]

>My questions: 
>1) Why this disparity in behavior between using explicit types (the first
>   code fragment) and typedefed types (second code fragment)?

For the same reason that, e.g.,

	typedef int *iptr_t;
	iptr_t a, b;

declares two pointers, rather than one pointer and one `int'.  Typedefs
are not like #define's.  Although typedef'd names are not *new* types---
they are simply alternative names for *existing* types---they must be
treated as atomic entities.  Hence, `const' cannot `penetrate' a typedef.

Consider, e.g.,

	typedef double value_t;
	const value_t x = X_INIT;
	value_t const y = Y_INIT;

In this case, x and y are obviously both intended to be read-only.
Suppose we later decide to change the representation of a value_t
so that we can share values:

	typedef struct vblock {
		int	refcount;
		double	val;
	} *value_t;

Because `const' does not penetrate typedefs, x and y remain `const'.
If it did penetrate typedefs, suddenly x would be read/write, pointing
to a read-only `struct vblock', while y would remain read-only and
would point to a read/write `struct vblock'.

>2) Is it possible to make a declaration of a pointer to constant data
>   using the typdefed int_pointer?

No.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Xref: sparky comp.lang.c:19567 comp.lang.c++:18986
From: ac690@cleveland.Freenet.Edu (Edward Klimas)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: C/C++ Speed
Date: 12 Jan 1993 06:22:30 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: ac690@cleveland.Freenet.Edu (Edward Klimas)
NNTP-Posting-Host: slc4.ins.cwru.edu


In a previous article, dliao@aludra.usc.edu (David Liao) says:

>	Two programmers are writing the same program but with different
>languages which are C and C++.  These two programmers are experts in 
>their own programming language.  Hmm... which program will run faster
>than the other?
>
>	I've heard that the execution speed of C++ tends to be slower
>than C.  I know that C++ can make the life of programmer easier, but
>I just want to know if the C program will run faster than the C++ program.
	The programing environment with the largest reusable library
	will usually end up being the fastest!  A little surprising
	until one considers that there is about a 6:1 variation in performance
	of programs when one has multiple developers create the same
	end functionality.  If you have reusably libraries, they
	are probably already partially optimized for performance already.
	This phenomena seems to account for why large systems written
	in low level languages run the same or slower than the same systems
	written in higher level languages even though on a tight loop
	the lower level language is much faster.

>
>	I also heard the size of C++ program is generally bigger than C.
	And C is larger than assembly code!  Don't get caught in this
	potential misconception, although spagetti code will always
	take more memory, using OO supports fine grain reuse much better
	which in turn results in smaller programs

>I am a C programmer trying to learn C++.  So, don't blame me if I have 
>created any misconception about C++.
>
>
>David Liao
>dliao@aludra.usc.edu
>University of Southern California
>	
>
>
>
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Any hope for me..?
Date: 10 Jan 93 12:39:16 GMT
Organization: AND Software BV Rotterdam

In article <726355710snz@panache.demon.co.uk> raph@panache.demon.co.uk writes:
|When I employ programmers I prefer those with a degree in English or History
|or Physics, or anything except CS. They tend to have more rounded knowledge
|and don't think that they know it all.
|
|My experience of CS graduates is that, by and large, they have read nothing
|and know nothing that was not in their degree course.

I've been thinking about your preferences towards non CS graduates, but
I still find it a remarkable opinion. Here in the Netherlands, people 
with an degree in English or History (as you wrote) know next to nothing
about computers, mathematics and computer science. 

Are you actually telling us that, after you've employed those people,
you're retraining them? Don't you think that doing so would be very
cost ineffective. I estimate that it would take at least a year or so,
before these people start being productive. 

I'm not trying to tell you that CS graduates are always an _ideal_ choice,
but I don't see many alternatives besides physicians, mathematicians and
CS graduates. (that's what the loonies that walk around at our company, 
claim to be ;-)

kind regards,

Jos aka jos@and.nl
Xref: sparky comp.lang.c:19248 rec.humor:37385
From: ahummel@ems.cdc.com
Newsgroups: comp.lang.c,rec.humor
Subject: Re: Program to convert .EXE to a "C" source file?  I really need one!!
Date: 5 Jan 93 13:45:06 GMT
Reply-To: you@ems.cdc.com
Followup-To: comp.lang.c
Organization: Empros Systems International, a division of CDC

In article <1993Jan5.022305.21844@berlioz.nsc.com>, nelson@desktop.nsc.com (Taed Nelson) writes:
|> [The original poster wanted something to convert EXE's to C source.
|>   Subsequent postings have made fun of that person.]
|> 
|> What the original poster was probably thinking of was the recently-posted
|>   program that converted EXE's and COM's to assembly code.
|> 
|> BUT, it is not unreasonable to be looking for a tool to convert an EXE to C
|>   code.  Of course, it is near-impossible to convert it to the ORIGINAL C code
|>   (orignal variable names and whatnot are in the symbol table, of course), but
|>   not all that hard (compared to other daunting tasks) to convert it into
|>   EQUIVALENT C code.  Of course, optimization would make the task even more
|>   difficult due to some implied side effects.
|> 
|> Tools of this sort were used to do the first analyses of the InterNet Worm,
|>   both at Purdue and Berkeley, if I remember correctly.  The first Purdue
|>   paper, I believe, had a considerable discussion of this process.
|> 
|> Whether such tools exist for DOS compilers, and just how automated any of the
|>   decompilers are, I don't know...


Oh, Toto, I don't think we are in Rec.humor anymore!!
Newsgroups: comp.lang.c
From: ujd@pool.info.sunyit.edu (Jacek Dziembaj)
Subject: Re: Program to convert .EXE to a "C" source file?  I really need one!!
Organization: State University of New York -- Institute of Technology
Date: Thu, 7 Jan 1993 13:12:40 GMT

In article <C0B6x5.DA6@ulowell.ulowell.edu> mbrousse@cs.ulowell.edu (Marc Brousseau) writes:
>>>>Hello. 
>>>>	I am looking for a program that will take a .EXE or .COM file and
>>>>convert it into a "C" source file.  I saw one on one of the FTP sites today,
>>> [Stuff deleted]
>>I'd prefer a program that generates the RCS or SCCS archives the program was 
>>developed in, plus a makefile.  Architectural and design documents would be 
>>nice too.
>>----------------------------------------------------------------------------
>I want a printer that will run in reverse, taking in a document, and
>converting it to a word processor file. Word for Windows out of a
>newspaper would be nize.

I recommend any scanner.

-------------------------------------
Jacek Dziembaj ujd@sunyit.edu 
-------------------------------------
Newsgroups: comp.lang.c
From: roberts@g2syd.genasys.com.au (Robert Swan)
Subject: offsetof problems on DEC
Organization: Genasys II, Sydney, Australia
Date: Mon, 11 Jan 1993 00:19:37 GMT

Greetings.

When is a constant not a constant?  When you're compiling on a DEC
(Ultrix 4.3, C++/ANSI C compiler).  Enough of the (dull) wit then, here
is my problem.

Compiling the following code on the DEC generates an error message that
the case expression is not a constant...  strange that the same
expression is sufficiently constant to satisfy the earlier static
initialisation.

=================================================================
#include <stddef.h>

typedef struct
{
	int	bag;
}
SCUM;

static int trash = offsetof(SCUM, bag);

int
main(int argc,char * argv[])
{
	switch (trash)
	{
	case offsetof(SCUM, bag):
		break;
	}

	return (0);
}
=================================================================


I've heard reports of problems with compilers (DEC, SGI, SCO ?)  not
handling offsetof with particular array elements e.g.  in

	struct foo
	{
		char bar[4][20];
	};

	offsetof(foo, bar) is considered constant, but
	offsetof(foo, bar[2]) is not.

I suspect that my problem is related to this. Just when can the result of
the offsetof macro (used sensibly) be anything but constant?  While I
hesitate to point the finger at the compiler, this sure looks like a
compiler error to me (I know that HP, Sun and IBM have no complaints
about the same code).

Just as an aside, wouldn't it make more sense for offsetof to be of type
ptrdiff_t rather than size_t?  I usually want to use the offset, not the
size of the sub-structure...

Has anyone else had problems with offsetof?

Have fun,

Robert.
-- 
I used to be indecisive,   | Robert Swan, roberts@g2syd.genasys.com.au
but now I'm not so sure.   | Genasys II Pty. Ltd., North Sydney.
Newsgroups: comp.lang.c
From: swight@kean.ucs.mun.ca
Subject: MS-C Graphics Lib
Organization: Memorial University. St.John's Nfld, Canada
Date: Mon, 11 Jan 1993 06:46:52 GMT

I would really appriciate any information leading me to a MS C graphic 
library, that was FAST! (VERY FAST!), and supported VGA.
Does such a thing exist for MS-C?!?
Stephen Wight
From: ayoung@vax.oxford.ac.uk
Newsgroups: comp.lang.c
Subject: can't access p2c/ptoc - HELP
Date: 10 Jan 93 08:57:31 GMT
Organization: Oxford University VAX 6620


 I can't get hold of either p2c or ptoc - I can't get into it via anonymous FTP
(the link won't let me login) and my site doesn't store comp.sources.unix. 

 Does anyone have a copy of either (preferably both) codes they can email me
directly please?

	Cheers,
		Alan Y.
-------------------------------------------------------------------------------
     ___
    /   \   /                 |    /      Alan Young @ uk.ac.ox.vax
   /____/  /  ___    __       |___/
  /    /  /  /   |  /  |         /           "The bigger they are,
 /     \_/\__\__/|_/  /_________/               the harder they fall on you."
From: roy%cybrspc@cs.umn.edu (Roy M. Silvernail)
Newsgroups: comp.lang.c
Subject: struct vs. typedef
Date: Sat, 09 Jan 93 01:10:17 CST
Organization: Villa CyberSpace, Minneapolis, MN

In a current project, I have a structure that looks like

struct n {
    int x,y;
    struct n *last,*next, *up, *down;
    void (*show)(struct n *);
    int width;
    void **value;
};

No problem, you say... But I wanted to convert it to a typedef, to
simplify another struct (which has about 30 instances of this one), so
I tried

typedef struct {
    int x,y;
    ITEM *last,*next, *up, *down;
    void (*show)(ITEM *);
    int width;
    void **value;
} ITEM;

and my compiler barfs on the included ITEMs.  OK, off to the manual,
which sort of explains things, along with mentioning that typedefs and
structure tags are rarely, if ever, needed simultaneously.
Nevertheless, I ended up with

typedef struct n {
    int x,y;
    struct n *last,*next, *up, *down;
    void (*show)(struct n *);
    int width;
    void **value;
} ITEM;

Now, this works, but it sure seems clumsy.  Is this really the only way
to do this type of construct?  If not, is it the optimal solution, or is
there some extremely clever trick I'm missing?
--
Roy M. Silvernail --  roy%cybrspc@cs.umn.edu - OR-  cybrspc!roy@cs.umn.edu
  perl -e '$x = 1/20; print "Just my \$$x! (adjusted for inflation)\n"'
          "Does that not fit in with your plans?"
                      -- Mr Wiggen, of Ironside and Malone (Monty Python)
From: omarab@atlantis.CS.ORST.EDU (Scorpion)
Newsgroups: comp.lang.c
Subject: JOYSICK HANDLER HELP.... PLEASE EMAIL RESPONCE!!  Thanks...
Summary: I need some help on my joystick handler.  Please email responce...
Keywords: joystick C c++ help IBM
Date: 5 Jan 93 03:14:38 GMT
Organization: OSU CS Outreach Services, Corvallis, Oregon
NNTP-Posting-Host: atlantis.cs.orst.edu

I need some help with a joystick handler.  If you can help me, I would
appreciate it!!!

I originally wrote this program to control one joystick.  It made an int86
call (see code below) to set the registers to the X and Y coordinates for 
the joystick. I could then display the coordinates on screen.  Now I decided
to rewrite the program to display the coordinates for 2 joysticks.  According
to the book I was reading, the registers were assigned as follows:

AX = A joystick X coordinate value
BX = A joystick Y coordinate value
CX = B joystick X coordinate value
DX = B joystick Y coordinate value

Now here is the code I used so you guys can take a look at it:

int joyax,joyay,joybx,joyby;
void joystick()
{
  union REGS regs;

  regs.h.ah = 0x84;
  regs.x.dx = 1;
  int86(0x15,&regs,&regs);
  joyax=regs.x.ax;
  joyay=regs.x.bx;
}

Now this works just great.  I set the variables joyax and joyay to the AX and
BX registers as above.  Now in order to rewrite the program, I must set
joybx and joyby to regs.x.cx and regs.x.dx, respectively.  Now, the code would
look like this:

int joyax,joyay,joybx,joyby;
void joystick()
{
  union REGS inregs, outregs;

  inregs.h.ah = 0x84;
  inregs.x.dx = 1;
  int86(0x15,&inregs,&outregs);
  joyax=outregs.x.ax;
  joyay=outregs.x.bx;
  joybx=outregs.x.cx;
  joyby=outregs.x.dx;
}

Now, when I display these coordinates for the B joystick, the X axis works
and displays fine, but the Y axis displays a constant 0 on the screen.  Now
I got no errors on compile (No undecleared variables, etc) and I checked the
joystick, and it works great when running alone.  I don't have a real good
understanding of the int86 command so I may be screwing up there... but 
according to this book... it should work fine.  If you are wondering, it is
the 'PROGRAMMERS PROBLEM SOLVER', second edition, by Roboer Jourdain and
the Peter Norton Computing Group.  Now I was a little suspicious when It
set the regs.x.dx (at the top) to 1 and then I was making a call to set joyby
to that same value.  So I re-wrote it as above, using seperatue arrays for
input registers and output registers.  IT DOESN'T WORK HERE EITHER.  

If you can help me, please E-Mail your responce... it is better for me that
way because I have to log into a different machine that normal to access news..

Thanks alot guys....

----------------------------------------------------------------------------
Brendan O'Mara                                     omarab@jacobs.cs.orst.edu
----------------------------------------------------------------------------
-- 
-----------------------------------------------------------------------------
 Brendan O'Mara					Owner, Stealth Technologies,
 Email: omarab@jacobs.ucs.orst.edu		specializing in:
 Alias: Scorpion					
Newsgroups: comp.lang.c
From: matujos@elof.iit.edu (Joe Matusiewicz)
Subject: Re: Problem with string processing.
Organization: Illinois Institute of Technology, Chicago
Date: Wed, 6 Jan 93 02:04:20 GMT


    I'm the one that had the problem with string processing.  First,
I'd like to thank all of you who mailed me back the answer to my problem.
All the replys have been extremely helpful.  SeSecond, I just wanted to 
post a followup article.  
    The problem was most likely my use of calloc with one argument.  I
first used malloc and forgot that calloc required 2 parameters, so I 
accidentally forgot about that.   (But some of you might agree with me that
the stupidest errors are usually the hardest to find).  Anyway, here is
the final copy of my function (which is exactly what many of you suggested):

void add_char_to_str( char *str, int ch )
{
    while(*str != '\0')
        str++;
    *str++ = ch; 
    *str = '\0';
}

This funtion doesn't have to use dynamic memory allocation at all.  It 
simply moves the pointer, str, (which is actually a copy of the pointer, thus
it is not changed after the fuction is returned) to the end of the string, 
and the character is simply copied to the end.  The NULL character is 
appended after that to end the string to end it.  

I knew there had to be a simpler way, 'cause there always is.





 
P.S.- Thanks for all the additional tips cause I am in the process of learning
      good C prgramming style.

 
                                     Thanx again,
					Joe Matusiewicz.









Newsgroups: comp.lang.c