HDTenEightyP/NetNews huggingface dataset:
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: Paranoia, side effects, and optimizing compilers
Date: Fri, 14 Aug 1992 18:39:23 GMT
Organization: The Portland Group, Portland, OR

In article <DAVIS.92Aug14120003@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu  (John E. Davis) writes:
>Hi,
>
>   Consider:
>
>      unsigned char *p;   
>   
>      while (1)
>        {
>           p = CLine->data + Point;
>           if (*p > ' ') break;
>           del();
>        }
>
>Here CLine->data is a pointer of same type as p and Point is an integer.
>del() is a routine that has that might possibly do a realloc on
>CLine->data so p might change in the loop.
>
>Would an optimizing compiler asssume that p will not change in the loop,
>evaluate it once and assume it is fixed in the loop?  In this case, I would
>want to declare it as volatile but I'd rather not worry about these issues.
>Or should I?

As long as CLine is external (or can be accessed via external
variables), the compiler must assume (in the absence of fancy
interprocedural analysis) that any function call can change its value,
therefore p cannot be invariant in the loop.  Consider a more simple
example:

main()
{
    extern int i;
    int j;

    for (;;) {
	foo();
	if (i == 0) break;
    }
}

Since i is external, its value can be changed by foo(), so it must be
reloaded from memory after every call to foo().

volatile is only necessary for variables that might change due to events
that aren't explicitly specified (e.g., shared memory multiprocessor
systems, setjmp-longjmp, interrupt handlers, external hardware).
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
Newsgroups: comp.lang.c
From: snippe@prl.philips.nl (Snippe DM)
Subject: Re: Help : Encryption Algorithms
Organization: Philips Research Laboratories Eindhoven, Netherlands
Date: Thu, 20 Aug 1992 14:41:56 GMT

ebolog@elaine.ee.und.ac.za (EDWIN BOLOGNA : THIRD) writes:


>Does anyone out there happen to have PAS, C, or ASM source code to decode
>and code good encryption algorithms.
Have you ever tried uuencode/uudecode ?
It not only codes/decodes good encryption algorithms, but just about
anything!! :-) :-)

Dick
From: ted.jensen@spacebbs.com (Ted Jensen) 
Newsgroups: comp.lang.c
Subject: Re: Pointer/address r 2/2
Date: 22 Aug 92 14:47:00 GMT
Distribution: na
Organization: SPACE BBS - Menlo Park, CA - 10 Lines + 4gB - 415-323-4193
Reply-To: ted.jensen@spacebbs.com (Ted Jensen) 

>>> Continued from previous message
Thus I think that by virtue of the fact that we have two
different words for describing the a variable type (pointer) and
the contents stored in such a variable type (address) a
description of what is actually taking place when using pointers
_can_, in a sense, be made clearer than when using integers or
floats.  Unfortunately, few writers on the subject of C
programming appear to share this view.

Well, that's my 2 cents worth!  Comments?

Ted Jensen
---
 * SLMR 2.0 *
From: cmhui@cucs18.cs.cuhk.hk (Hui Chau Man)
Newsgroups: comp.lang.c
Subject: Oasys contact wanted
Date: 14 Aug 92 02:27:47 GMT
Organization: Faculty of Engineering, The Chinese U. of Hong Kong

Dear netters,

Can anybody tell me the contact FAX number of Oasys. Oasys is the
developer of Green Hill C and Green Hill C++ compiler.

Thanks in advance.


C.M. Hui
Dept. of Computer Science
The Chinese University of Hongkong
Shatin, N.T.
Hongkong

Internet: cmhui@cucs18.cs.cuhk.hk
FAX: (852) 6035024
Newsgroups: comp.lang.c,comp.programming
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: A LITTLE BRAINTEASER...
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 15 Aug 1992 00:25:04 GMT

halderen@fwi.uva.nl (Berry van Halderen (I88)) writes:

>The solutions so far posted were or: totally incorrect, did use datastructures
>(translating pascal ain't no good coz strings are datastructures)

The problem is not that the translation may introduce strings; there were
no strings in the Pascal program posted. The problem is that the translation
will almost certainly introduce pointers and structures.

>or we're hacking around on the stack. This can lead to porting problems.
>ANSI-C and most Classic C compilers do provide variable number of arguments.
>Using this, I think I have found a solution that is cleaner. Dirty still.

[... Program that uses varargs to access stack ...]

>It works. It implicitly builds a linked list into the stack. There are
>no pointers (well, ap is a pointer in most implementations) structs or
>whatever, and no calculation of stack addresses is done (which is cleaner).

Well, you can't be *sure* that there are no structs or dynamic allocation,
since you don't know how varargs is implemented. Clever idea, though.

Another way of solving the problem is to create a temporary file using the
old unbuffered i/o library. (You only need ints for the file-handles: no data
structures required! No structs, no pointer variables, no heap allocation, no
implicit linked lists, no hacking around the stack!). Just goes to show that
you've got to specify exactly what you mean when you say "no heap allocation
allowed" :-)

>If you don't even want a implicit list like this to be build, but want to
>work pure recursively: It cannot be done!
>Prove? Neh, I don't want to prove it, but after a sleepless night I'm quite
>certain. I do however think it can be done if you know the number of
>characters per each line before reading each line.
>
>A different remark: DONT use main functions recursively! Some compilers
>rely on this. I even believe that in the C definition it says that you
>may not call the main() function from any routine. It is also bad
>programming!

I am fairly sure than ANSI C explicitly sanctifies this practice (although
C++ explicitly disallows it). Any compiler that claims to be an ANSI C
compiler and that can't handle recursive calls to main() is broken.

As for bad programming, well, beauty is in the eye of the beholder.
I happen to think that recursive calls to main() are cute :-)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c
From: thompson@atlas.socsci.umn.edu (T. Scott Thompson)
Subject: Re: POWER OF LARGE NUMBERS
Reply-To: thompson@atlas.socsci.umn.edu
Organization: University of Minnesota
Date: Tue, 18 Aug 1992 16:40:01 GMT

cgay@majestix.cs.uoregon.edu (Carl L. Gay) writes:

>? (time (expt (expt 6 6) 6))
>(EXPT (EXPT 6 6) 6) took 34 milliseconds (0.034 seconds) to run.
> 56 bytes of memory allocated.
>10314424798490535546171949056
>? (time (expt 6 (expt 6 6)))
>(EXPT 6 (EXPT 6 6)) took 32290 milliseconds (32.290 seconds) to run.
>Of that, 120 milliseconds (0.120 seconds) were spent in The Cooperative Multitasking Experience.
> 30464 bytes of memory allocated.
>265...36300 digits removed...656

>Just provided for your amusement...

Alright!  Who volunteers for 7 ^ (7 ^ 7)?
                                ...
                             10 ^ (10 ^ 10) ?

P.S.  Mathematica 2.1 on a Sparc 2 does 6 ^ (6 ^ 6) in 5.02 CPU seconds.
Newsgroups: comp.lang.c
From: Ross Ridge <ross@zooid.guild.org>
Subject: Re: why does #define Ctrl(c) c&037 work ?
Organization: ZOOiD BBS
Distribution: worrrld
Date: Sun, 16 Aug 1992 22:40:49 GMT

fin@unet.umn.edu (Craig A. Finseth) writes:
>The "correct" macro should be:
>
>#define Ctl(c) ((c)^'@')
>
>Which works for all of the above, and ? too.
>
>On the other hand, the GNU form picks up the lower case letters (as in
>^a), but I at least would consider that usage to be silly, and
>certainly not worth giving up ^? for.

The macro is pretty bogus to begin with.  It only exists because
it used to be:

	#define Ctl(c) ('c'&037)

While unportable and just as bogus, it was at least convienent.  eg:

	char eof = Ctl(D);

Otherwise you might as well just do:

	#define CTL_A	'\001'
	...
	#define ESC	'\033'
	...

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //
From: Jon Freivald <jaf@jaflrn.UUCP>
Newsgroups: comp.lang.c
Subject: Re: Routine to disable Ctrl-Alt-Del on PC
Date: Fri, 14 Aug 92 21:36:15 EDT
Organization: The Wizzard's Cave, East Meadow, NY

u9035710@cs.uow.edu.au (Scott Anthony Barnett) writes:

> Help !!
> 
> I am after a little routine (either in C or inline assembler) to simply
> disable the Ctrl-Alt-Del interrupt on an IBM PC.
> 
> I am using Borland C++ v 3.0 (in standard ANSI C).
> 
> Also, I would like to disable Ctrl-Break.
> 
> Any help would be appreciated.

I'm interested in the Ctrl-Alt-Del myself.  As for the
Ctrl-Break/Ctrl-C, the following works fine:

#define	CTRLC	0x23
#define CTRLBRK	0x1B

void	interrupt break_handler ( void );
void	disable_ctrl_break ( void );
void	enable_ctrl_break ( void );

void interrupt ( *original_ctrl_c_handler ) ( void );
void interrupt ( *original_break_handler ) ( void );

/============================================================================

void interrupt break_handler ( void )

{
	return;		// do nothing - simply catching ctrl-c/ctrl-break
}

//===========================================================================

void disable_ctrl_break ( void )

{
	original_ctrl_c_handler = getvect ( CTRLC );	// get original vector address
	original_break_handler = getvect ( CTRLBRK );
	setvect ( CTRLC, break_handler );		// install our handler
	setvect ( CTRLBRK, break_handler );
	atexit ( enable_ctrl_break );			// insure original handler is reinstalled
							//    no matter how or when we exit program
	return;
}

//===========================================================================

void enable_ctrl_break ( void )

{
	setvect ( CTRLC, original_ctrl_c_handler);
	setvect ( CTRLBRK, original_break_handler);
	return;
}

//===========================================================================

Hope this helps...

Jon

=============================================================================
		   Jon Freivald ( jaflrn!jaf@uunet.UU.NET )
	 Nothing is impossible for the man who doesn't have to do it.
=============================================================================
From: stefan@zurich.ai.mit.edu (Stefan Kozlowski)
Newsgroups: comp.lang.c
Subject: Wanted: Source code for a grep function for DOS
Date: 16 Aug 92 21:51:06 GMT
Reply-To: stefan@zurich.ai.mit.edu
Distribution: comp.lang.c
Organization: M.I.T. Artificial Intelligence Lab.


If you also know of an ftp site with lots of useful public domain C
code, the address would also be greatly apprecited. 

Thanks.

--Stefan Kozlowski
  stefan@zurich.ai.mit.edu
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: <None>
Date: 13 Aug 92 10:35:02 GMT
Organization: AND Software BV Rotterdam

In article <1992Aug13.044258.8274@news.ysu.edu> af458@yfn.ysu.edu (Jon K. Salmon) writes:
|lou1347@cucs17.cs.cuhk.hk writes:
|
|>   code=(*video++)+(*video++ & 8)?256:0;
|
|> This subroutine gets the ascii in video times the bit 3 in attribute,
|> but it gets the wrong result.  So I changed it to:
|
|>   code=*video++;
|>   code+=(*video++ & 8)?256:0;
|
|> I split the line into two parts and then it works correctly.
|> But I don't know why.  Can you tell what's wrong?
|
|The addition operator has higher precedence than the ternary
|operator.  Thus, while your intent was to see if (*video++ & 8)
|was non-zero, you were actually comparing (*video++)+(*video++ & 8)
|to zero and selecting from the ternary operator.  Hence, the
|variable "code" was always being set to either 256 or 0, NOT
|(*video++) PLUS 256 or 0, as you intended.

Even if the operator precedence _were_ the way the original poster wanted
it to be, this is still non-conformant code. The first sequence point here
is at the location of the semicolon. Before this sequence point is 
reached, the variable `video' is incremented twice. It doesn't matter
whether or not the `+' operator is a left associative operator, the
compiler is free to generate code that evaluates (*video++ & 8) before
evaluating (*video++).

Splitting up the assignment into two assignment expression is the correct
way of solving this: it introduces another (needed) sequence point.

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: u8705957@cs.uow.edu.au (Hitesh Sanghvi)
Subject: HELP ! DIFFIE HELLMAN SCHEME
Organization: Dept of Computer Science, Wollongong University, Australia
Date: Mon, 17 Aug 1992 08:42:30 GMT

Hello there;

	If you know How to obtain diffie hellman code for public key

cryptography , Please pass it over to me.

Any hints.

Hitesh
Newsgroups: comp.lang.c
Subject: Help : Extended and Expanded Memory
From: ebolog@elaine.ee.und.ac.za (EDWIN BOLOGNA : THIRD)
Date: 20 Aug 92 12:55:53 +0200
Organization: Electronic Eng., Univ. Natal, Durban, South Africa


Does anyone out there happen to have PAS, C, or ASM source code that is
able to access Extended or Expanded memory. This computer has got Three Mbytes

Extended memory and I am unable to use any of it in my programs.

Any information at all on this will be greatly appreciated.

        Desperate fellow programmer (And very Greatful for any information)

                E.B. (EBOLOG@ELAINE.EE.UND.AC.ZA)

PS : Please be kind hearted and Assist !
Newsgroups: comp.lang.c
From: af458@yfn.ysu.edu (Jon K. Salmon)
Subject: Re: <None>
Organization: Youngstown State University/Youngstown Free-Net
Date: Thu, 13 Aug 1992 04:42:58 GMT


lou1347@cucs17.cs.cuhk.hk writes:

  [some code deleted]

>   code=(*video++)+(*video++ & 8)?256:0;

> This subroutine gets the ascii in video times the bit 3 in attribute,
> but it gets the wrong result.  So I changed it to:

  [more code deleted]

>   code=*video++;
>   code+=(*video++ & 8)?256:0;

> I split the line into two parts and then it works correctly.
> But I don't know why.  Can you tell what's wrong?

The addition operator has higher precedence than the ternary
operator.  Thus, while your intent was to see if (*video++ & 8)
was non-zero, you were actually comparing (*video++)+(*video++ & 8)
to zero and selecting from the ternary operator.  Hence, the
variable "code" was always being set to either 256 or 0, NOT
(*video++) PLUS 256 or 0, as you intended.

-- Jon
-- 
Newsgroups: comp.lang.c
From: greyham@research.canon.oz.au (Graham Stoney)
Subject: I wish ANSI-C sizeof (void) == 1 (was Re: preprocessing subterfuge)
Organization: Canon Information Systems Research Australia
Date: Thu, 13 Aug 1992 04:13:16 GMT

toriver@flipper.pvv.unit.no (Tor Iver Wilhelmsen) writes:

>In article <1992Aug10.031337.4424@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>>Gnu C with -Wall -ansi -pedantic has a pretty tight sphincter.

>May be, but it still insists on assigining a size of 1 (one) to the type void,
>which according to the parts of the standards I have seen, is an incomplete type.
>Thus you get a warning:
>void.c:3: warning: sizeof applied to a void type

When I first heard of GNU C's deviation from the standard with the sizeof type
'void', I thought it was a bad idea; but now I hope ANSI will standardise it
next time around. void * is the natural type to use when you're considering a
pointer to a chunk of memory that can hold any arbitrary type; in the Unix
kernel for instance it seems a natural replacement for caddr_t. And any time
I need to do arithmetic on one, it's always in terms of bytes - it would be
great to be able to not have to cast to char * every time you need to do
arithmetic on one, which seems to happen quite a lot in stuff like device
drivers.

Any comments?

Graham
-- 
Graham Stoney                    | "a Perl script is correct if it's halfway
Flip Dibner fan club, "Hi Flip!" |  readable and gets the job done before your
Ph: +61 2 805-2909  Fax: -2929   |  boss fires you." L. Wall & R. Schwartz
From: gordon@osiris.cso.uiuc.edu (John Gordon)
Newsgroups: comp.lang.c
Subject: Re: Knight's tour
Date: 13 Aug 92 00:04:57 GMT
Organization: University of Illinois at Urbana

pedersen@seas.smu.edu (Ted Pedersen) writes:

>Anyone out there have any nice Knight's Tour code (or know where it can
>be readily obtained)?  

>(Note : the Knight's Tour is a problem where you try and make a knight  
> visit all of the squares of a chess board (without repitition) and having 
> your knight return to it's original starting point. I don't think I said
> it very well but I hope the idea is sort of clear for those who haven't
> heard of the problem.)

>Actually what would be a dream come true is if there is an ftp site or a book
>that has programs that solve some of the classical chess problems (n - queens
>and knights tour are good examples of that). Hope someone can help. Thanks.   

	The "What's The Code?" column in Computer Shopper magazine recently
printed an article on the Knight's Tour, and I think it has dealt with
a queen-related problem too.  It really is a neat column, I have saved many
articles from it, ranging from CPU caching schemes to the aforementioned
Knight's Tour problem.  Email me if you want the exact issue date.

---
John Gordon                        My incredibly witty saying has been 
gordon@osiris.cso.uiuc.edu         Politically Corrected into oblivion.
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Variable field width portable? (was question about \t)
Date: 17 Aug 92 21:05:23 GMT
Organization: University of Helsinki

dharris@trirex.com writes:
>Jutta Degener writes
>>To print a string indented by n spaces:
>>
>>	printf("%*s%s\n", n, "", string);
>>
>
>Is this portable?  I'd never seen this before and it's not in the ANSI
>C book that I have (_The Waite Group's Essential Guide to ANSI C_), but
>it compiles and runs as advertised under NeXT's GNU C compiler...

It's in ANSI C (your book seems to be lacking in this regard), but not
in every non-ANSI library.  If you need it badly enough, you can
simulate this by creating the format string runtime, e.g. with

	#define FMT	"%%%ds%%s\n"
	char format_string[ sizeof(FMT) + sizeof("1234567898012345678980") ];
	sprintf(format_string, FMT, n);
	printf(format_string, "", string);

(Untested code!  Sorry.)

--
Lars.Wirzenius@helsinki.fi
Newsgroups: comp.lang.c
From: ebergman@nyx.cs.du.edu (Eric Bergman-Terrell)
Subject: Re: How can a program know where it was invoked?
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Wed, 12 Aug 92 14:10:25 GMT

In article <31460023@hpcuhe.cup.hp.com> jbc@hpcuhe.cup.hp.com (Jeff Caldwell) writes:
>>	I would like to know how does a program knows where it was invoked?
>>	For example, 
>>	can foo detect where its binary execution file is?
>
>One rudimentary method is to use "system".  Compile the following and run it:
>
>     #include <stdlib.h>
>     
>     main(argc, argv)
>      int argc;
>      char     *argv[];
>     {
>        char string[20];
>        sprintf(&string, "which %s", argv[0]);
>        system(string);
>     }
>
>			-Jeff Caldwell
>


What about looking at argv[0].  Isn't this a reasonably portable way of
ascertaining the pathname of the executable? 

Terrell
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Using fscanf with files
Date: 22 Aug 92 09:32:35 GMT
Organization: University of Helsinki

CS19241103D@LUST2.LATROBE.EDU.AU (TELFORD, ROD) writes:
>basically I want to read in a line terimnated by a line feed using fscanf()

Use fgets.  

--
Lars.Wirzenius@helsinki.fi
Newsgroups: comp.lang.c
From: miller@eemips.tamu.edu (Kelly M Miller)
Subject: Borland using MSC libs
Keywords: libs obj borland bcc msc
Organization: Texas A&M University
Distribution: comp.lang.c
Date: Thu, 13 Aug 1992 18:22:40 GMT


Is it possible to link in libs created under MSC 5.0
into a Borland C app? What must I include in the link?
the MSC libs? Must I exclude some of the Borland libs?

I would appreciate your help. 


kelly
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Simple C question
Date: 22 Aug 1992 19:24:31 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <_c+nnmp@lynx.unm.edu> rsahu@triton.unm.edu (Raikanta Sahu) writes:
>Distribution: unm
(that distribution worked really well, I see :-) )
>I thought the following piece of code was perfectly legal.

It has one bug (it returns a random value from main()), but is otherwise
legal.

> char s[] = "Hello world!" ;
>ccom: Error: test.c, line 6: no automatic aggregate initialization

You have an legal C program, but an illegal compiler. :-)

More precisely, compilers that print

	no automatic aggregate initialization

are derivatives of the Portable C Compiler (PCC), a rather ancient and
creaky compiler that predates the ANSI C standard by more than a decade.
PCC is nowhere near ANSI-conformant.  Your best bet is to discard the
current system and get one that at least *attempts* to be conformant.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.lang.c
From: jedwards@gmuvax2.gmu.edu (James Edwards)
Subject: Memory problems....
Organization: George Mason University, Fairfax, Va.
Date: Mon, 17 Aug 1992 18:48:18 GMT

I am really having a rough time trying to understand this.  I am writing
C code on a Sparc 2 with 32mb of RAM, and about 100mb of swap space.  It
seems to me that there must be some limiting factor as to why I can't
create an array around 10mb in size.  I've tried this both globally and
using the routines in the FAQ to create the array dynamically; both to
no avail.  What is the problem here?  I haven't found anything in any of
the sun manuals that talks about max global array sizes, or any compiler
limitations, but something is definately screwing things up.  If anyone
has any advice, hints, whatever; it would be greatly appreciated.

Jimi

Newsgroups: comp.lang.c
From: ptran@envmsa.eas.asu.edu (Phi-Long Tran)
Subject: Re: argv[1][1] OK, argv[1][0] Not? Huh?
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: Arizona State University, Tempe, AZ
Date: Fri, 21 Aug 1992 07:45:00 GMT

In article <1992Aug20.222254.566@lambda.msfc.nasa.gov>, 
puckett@lambda.msfc.nasa.gov (Jim Puckett) writes...

>In a little application, I ran into this problem...

>if (argv[1][0] != '-' ) 
>	would cause a core dump, while

>if (argv[1][1] != 'P' ) 
>	wouldn't.

     If you included more of the code and a sample run, then it would shed
more light on the source of the problem.

---
Phi-Long Tran
ptran@asuvax.eas.asu.edu
Arizona State University
From: 754clifton@gw.wmich.edu
Newsgroups: comp.lang.c
Subject: Help: read() question.
Date: 21 Aug 92 15:44:01 EST
Organization: Western Michigan University

Assuming I have a file I have found the exact size (len) of using lseek or
some other method. Assume also that I have a valid file descriptor, and a
char *buf allocated to hold the data, shouldn't the call:

	nread = read(fd, buf, len); 

return (nread) the same number of bytes as the length? ie. nread == len if
there where no errors from read? In a bug search I am working on this call`
returns *1 less* than the number of bytes in the file, which screws-up the
error checking on the file that the code is indended for.

Thanks for any advice,

/Doug
--
Douglas Clifton [99clifto@lab.cc.wmich.edu]