HDTenEightyP/NetNews huggingface dataset:
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Subject: Re: Pointer/address reluctance
Originator: sasghm@theseus.unx.sas.com
Date: Mon, 17 Aug 1992 18:22:12 GMT
Organization: SAS Institute Inc.


In article <mcdonald.206@aries.scs.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:

|> 
|> However, in fact pointers **are** addresses of a sort, and the real
|> programmer nees to understand them if they are to do general programming in
|> C.
|> 
|> This can, in fact, be proven:
|> 
|> 1) General programming includes all the programming that can, and is,
|>    done in C
|> 
|> 2) Some C programming is for interaction with devices, for example,
|>    direct control of devices from programs and/or device drivers if an OS
|>    uses such beasties.
|> 
|> 3) Some devices use memory mapped magic addresses
|> 
|> 4) IF these can be addressed from C, which is usually the case (for example,
|>    C code running in   "unhosted" mode at the highest privilege level),
|>    then the usual way to address them  is by actually coding the proper bits
|>    into an integral variable (or in rare cases the integral part of a union)
|>    and casing to a pointer.
|> 
|> QED.
|> 
|> 
|> Of course, there are some individuals who aren't interested in such 
|> things ..  or aren't trusted enough to do it.
|> 
|> Doug McDonald   

If you need to understand them, you need to understand them a little
better.  While there is a (sometimes very) close relationship between
addresses and pointers in C, they are not the same.  Consider, for
example, the fact that there are some memory models for the 8086
where a pointer (say a function pointer) is two bytes in size, but
the address it represents is four bytes in size.  The Lattice P
model had this feature, and our mainframe C compiler implements
a similar scheme as well.  So pointers aren't even necessarily the
*same size* as addresses.

This brings up the point that there is no requirement for all
pointers to be the same size.  It is not uncommon for function
pointers to be a different size from data pointers.  Does this
mean or require that the underlying machine supports two different
kinds of addresses?  Hardly.

In addition, of course, as a previous poster pointed out, a pointer
comes with the additional semantic baggage concerning the size of
the pointed-to object.

-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
Newsgroups: comp.lang.c
Subject: Re: Byte Order Question
From: a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
Date: 20 Aug 92 15:25:54 GMT

In <1992Aug20.131614.23729@bnrmtl.bnr.ca> john@bnrmtl.bnr.ca (John Hickin) writes:

>Forgive me if this is a FAQ but here goes.

>Suppose int's are 2 bytes.  Then division of a positive number by 256 should
>retrieve the most significant byte of the int.  What about a right shift by 8?
>My suspicion is that the result of the shift of a positive number could depend
>on whether the byte order is big or little endian.  Is my suspicion correct?

Nope.  It must produce the same result (for a positive number).
--
Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
My opinions are my own, and do not represent those of my employer.
My interaction with our news system is unstable; if you want to be sure I see a post, mail it.
Newsgroups: comp.lang.c
From: bcschu@skws02.monsanto.com (Brett Schultz)
Subject: Re: Optimizing code for tests
Organization: Monsanto Company
Date: Fri, 14 Aug 1992 20:20:06 GMT

amorgan@Xenon.Stanford.EDU (Crunchy Frog) writes:
: In article <1992Aug14.192350.4786@tin.monsanto.com> bcschu@skws02.monsanto.com (Brett Schultz) writes:
: >
: >Many of you have also suggested to look for bottlenecks in my program.
: >I appreciate the info, but I have already found the bottlenecks and just
: >thought that optimized code runs faster than non-optimized code (esp. when
: >compiled with debugging info).  
: 
: Hold on, are you compiling with debugging on?  Most compilers (GCC being
: one of the few exceptions) do not do optimization and debugging at the
: same time.  Is this your problem?
: 

No, I said optimized code .vs. non-optimized code and the non-opt. code 
should especially be slow with the debug switch on.

: I am not sure what the -j option does, but if the manual says to
: use it, use it :-).
:   
: >Brett
: 
: C Frog
:\

What I am saying is that, the optimized code did not run faster than non-opt.
code (non-opt. included -g switch, debug info).

Does anyone know the correct way to optimize C code using the cc compiler via
a Unix Makefile.

Thanks

Brett
From: paul@svl.cdc.com (Paul Kohlmiller)
Newsgroups: comp.lang.c
Subject: Re: Is "...", instead of ",..." legal ?
Keywords: variable arguments
Date: 13 Aug 92 23:21:41 GMT

--
     // Paul H. Kohlmiller             //  "Cybers, Macs and Mips"    //
     // Control Data Systems, Inc.    // Internet: paul@svl.cdc.com  //
     // Acronym under construction.  // America Online: Paul CDC    //
     // All comments are strictly my own. I won't lie but my       //
     // perception of reality is at best a personal hunch.        //
Newsgroups: comp.lang.c
From: tim@rcsl.demon.co.uk (Tim Frost)
Subject: Linker Error: Segment _TEXT exceeds 64K 
Distribution: world
Organization: Roundhill Computer Systems Limited
Date: Fri, 21 Aug 1992 19:43:53 +0000


In article <drice.714378305@ponder> drice@ponder.csci.unt.edu writes:

>
>In <1992Aug21.010511.15329@cc.umontreal.ca> desmarai@ERE.UMontreal.CA> (Desmarais Normand) writes:
>
>>"Linker Error:  Segment _TEXT exceeds 64K"
>
>Try compiling it with a COMPACT memory model.
>

No!  Compact gives you the same 64k limit for code (TEXT) as does the default
small model.  You need Medium or Large model to get past this limit.  

Read the section in the programmer's guide about memory models for more info.


:::: Tim Frost :::::::::::::: Roundhill Computer Systems Limited ::::
:::::::::::::::::::::::::::::::::::: Marlborough SN8 1SU England ::::
:::: tim@rcsl.demon.co.uk :::::::: +44 (0) 672 84 535 (fax: 525) ::::
From: mwilson@ncratl.AtlantaGA.NCR.COM (Mark Wilson)
Newsgroups: comp.lang.c
Subject: Re: A question on style ...
Date: 13 Aug 92 21:20:36 GMT
Organization: NCR Engineering and Manufacturing Atlanta -- Atlanta, GA

Just a test sorry.
-- 
--Mark
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: I wish ANSI-C sizeof (void) == 1 (was Re: preprocessing subterfuge)
Date: 19 Aug 92 22:33:20 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <Bt5n8A.41B@research.canon.oz.au>, greyham@research.canon.oz.au (Graham Stoney) writes:
|> volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
|> >If you need to do arithmetic on one, then the variable should not be declared
|> >as "void *" in the first place. That type is for pointing to objects whose
|> >size you don't know. If you know you're going to be dealing with arrays of
|> >bytes, then declare it as "[unsigned] char *". 
|> 
|> Yes, but I'm _not_ dealing with arrays of bytes. I'm pointing to arbitrary
|> locations which store as yet unknown types. One example is converting a
|> pointer in shared memory from one virtual address space to another. Another
|> is adding the base address of a hardware device to the address at which the
|> block of address space in which it resides is mapped. You really aren't
|> dealing with arrays of bytes, just memory addresses; you can't dereference
|> them, but sometimes you need to add to them.

When you do such operations, you are treating the block of memory as an
array of bytes. A shared memory segment is an array of bytes. When you 
convert between virtual address spaces, you are subtracting the start
address of the segment from the pointer in question. Thus, you are
doing pointer arithmetic on that big char array returned by shmat(2), 
regardless of what structure-pointer-type you are going to convert the
pointer to later. 

There's no need to make (void *) behave like (char *). If you want 
a (char *), you know where to find it.

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

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: cgay@majestix.cs.uoregon.edu (Carl L. Gay)
Newsgroups: comp.lang.c
Subject: Re: POWER OF LARGE NUMBERS
Date: 18 Aug 92 06:32:08 GMT
	<thompson.713734408@daphne.socsci.umn.edu>
	<1992Aug16.052157.1991@organpipe.uug.arizona.edu>
	<1992Aug17.222948.10070@merlin.dev.cdx.mot.com>
Reply-To: cgay@cs.uoregon.edu
Organization: CS Dept, University of Oregon


   From: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
   Date: Mon, 17 Aug 1992 22:29:48 GMT

   In article <1992Aug16.052157.1991@organpipe.uug.arizona.edu>, dave@cs.arizona.edu (Dave Schaumann) writes:
   |>>
   |>>>	Does any one know how to raise power of possibly 100 digits 
   |>>>to possibly 100 digits. Any algorithm or code will be appriciated.
   |>>
   |>>>Example >(1234367463746464647464...up to 100 digit)**(647254627463048736...up to 100 digit)
   |>>
   |>>The order of magnitude of the solution to this problem is 
   |>>
   |>>              10**(10**102)
   |>>
   |>>which is a ridiculously large number.
   |>>Is there any hope of solving this?
   |>

   It seems that an accurate answer might take rather a long time...

   On a connected note, I once wrote a  program to calculate 6^6^6.  My
   first attempt actually calculated (6^6)^6 and ran fairly quickly; my
   second attempt calculated 6^(6^6) and ran overnight on a VAX 11/780.
   It did it by taking 6^6 as a constant and used variable length arithmetic
   to multiply a variable-length number repeatedly by 6 that number of times.
   The variable length arithmetic may not have been optimal, 

Um, it almost certainly wasn't.  On a Mac IIsi, in Lisp (sorry, I
don't want to write it in C):

? (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...

-Carl
Newsgroups: comp.lang.c
From: Ross Ridge <ross@zooid.guild.org>
Subject: Re: Memory alignment of struct elements
Organization: ZOOiD BBS
Date: Mon, 17 Aug 1992 23:08:11 GMT

adam@microware.com (Adam Goldberg) writes:
>That's all well and good, but what if, say, you are coding an implementation
>of LIM EMS 4.0, which takes as a parameter a structure which, in assembler,
>looks like this:
>
>Parm Struct
>MemIn      dd   ?   ; 4 bytes
>MemIType   db   ?   ; 1 byte
>MemISize   dw   ?   ; 2 bytes
>MemOut     dd   ?   ; 4 bytes
>MemOType   db   ?   ; 1 byte	
>MemOSize   dw   ?   ; 2 bytes
>Parm Struct
>
>In C, this *could* be :
>
>typedef struct PARM {
>  char *MemIn, MemIType;
>  short MemISize;
>  char *MemOut, MemOType;
>  short MemOSize;
>} PARM, *pPARM;
>
>Except for the addition of superflourous padding bytes.  Is there any
>standard way to FORCE the C Struct to be identical to the Asm struct?

No, of course not, on some machine architechures it's impossible 
define a struct like yours without necessary, not superflourous, padding
in assembly or not.  In fact there is no standard way specfiying
a two byte wide member value, there is no guarantee that shorts are
this size.  In fact even MS-DOS C compilers don't guarantee that the char
pointers will be 4 bytes wide, compile this in the wrong mode and they'll
be 2 bytes wide.  

>No, I didn't think so.  There ought to be, though.  I've been forced to
>do nasty things like:
>
>typedef struct PARM {
>  char MemIn[4], MemIType, MemISize[2];
>  char MemOut[4],MemOType, MemOSize[2];
>};

Why not do something "nasty" like this:

	#pragma pack(1)		/* for MSC */
	#pragma option -a-	/* for Borland C */

Since you're defining an extreamly OS specific structure, you might
as well use a compiler specific feature.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //
Newsgroups: comp.lang.c,gnu.gcc,gnu.gcc.help
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: gcc-cpp chokes: bug or feature?
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Tue, 18 Aug 1992 03:25:13 GMT

In article <BszKpr.GBu@cs.columbia.edu> leland@cs.columbia.edu (Leland Woodbury) writes:
>Why is it parsing what should be getting ifdef'd out?

	/* example #1 */
	#if 0
	/*
	#else
	/* */
	printf("hello\n");
	#endif
Does the preprocessor ignore everything between #if 0 and #else, in which
case the printf() is active (since it's between the #else and #endif)?  Or is
`/* #else /* */' merely a comment, in which case the printf() is inactive?

Answer: Both Classic C and ANSI C use the latter interpretation.  Hence the
preprocessor must do lexing of comments, even inside if'd out sections.

	/* example #2 */
	#if 0
	"\
	#else /*"/**/
	printf("hello\n");
	#endif

This case is similar: the #if'd block contains a string literal (which happens
to include a continuation line), a comment (which happens to include an
embedded `/*'), and a printf().  It does not include an #else.  Again, Classic
C and ANSI C agree on this.

So you see, the preprocessor has always done lexical analysis within #if'd
blocks, even in Classic C.  It happens that the Reiser preprocessor, when
it encountered an unescaped newline inside a string literal or character
constant, would silently close the quotes.  This was one of several
arbitrary decisions that were documented in the preamble to the cpp source.
(Fascinating reading; I didn't realize how many loopholes there were in the
informal K&R specification.)  ANSI C did not require this particular quirk,
and the GNU people chose to produce a diagnostic for it instead.

I personally prefer the diagnostic.  I don't like having compilers play "guess
what I'm thinking, and compile it".

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.lang.c
From: markh@csd4.csd.uwm.edu (Hunk)
Subject: Re: Pointer/address reluctance
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Thu, 13 Aug 1992 15:27:53 GMT

In article <l8kteaINNp2c@exodus.Eng.Sun.COM> linden@positive.Eng.Sun.COM (Peter van der Linden) writes:
>Can anyone explain the reluctance that some of the experts here
>have in equating "pointer" with "address"?

Pointer = Address + Type of object being pointed to.
From: atmtjkv@vax.oxford.ac.uk
Newsgroups: comp.lang.c
Subject: Re: Question about lex
Date: 14 Aug 92 08:13:21 GMT
Organization: Oxford University VAX 6620

In article <1992Aug13.145803.3008@ccd.harris.com>, 
djs@controls.ccd.harris.com (Dan J. Smith) writes:
> 
> 
> I'm trying to call the lex output functions generated by two different lex input
> files from the same program. But, they both generate output functions called
> yylex and have the same global variables so this does not work.
> 
> My question is: Is there any way to link two lex output files into
> the same program. I've had several ideas but they turned into dead ends pretty 
> quickly.
> 
> 
> Thanks in advance.
> Dan Smith
> djs@ccd.harris.com
> 
Try changing all the 'yy's in one of the lex.yy.c s to something else,
watching for what's defined in the -ll library
which in my case (sun4/sunos 4.1) contains:
	allprint.o
	main.o
	reject.o
	yyless.o
	yywrap.o
so to produce a linkable object file from lex.zz.c you'll probably need
	cc -c lex.zz.c -Dzzwrap=yywrap -Dzzless=yyless -ll -o lex.zz.o

I tried this, as follows:

german.lex:
%%
french  { printf("switching to french"); return; }
hello   printf("guten tag");
goodbye printf("auf wiedersehen");
.                       printf(yytext);
\n                      printf("\n");
%%

french.lex:
%%
german  { printf("switching to german\n"); return; }
hello   printf("bonjour");
goodbye printf("au revoir");
.                       printf(yytext);
\n                      printf("\n");
%%

main.c:
main()
{
  while (1) {
    fflex();	/* alternates between french and german parsers until ^C */
    gglex();
  }
}

lex french.lex
sed s/yy/ff/g < lex.yy.c > lex.ff.c
cc -c lex.ff.c -Dffwrap=yywrap -Dffless=yyless -o lex.ff.o

lex german.lex
sed s/yy/gg/g < lex.yy.c > lex.gg.c
cc -c lex.gg.c -Dggwrap=yywrap -Dggless=yyless -o lex.gg.o

cc main.c lex.ff.o lex.gg.o -ll -o ltest

.... and it works as expected.  No guarantees in a more complicated program,
though maybe this will help a bit!

-- 
Tim Kingsmill-Vellacott
Atmospheric, Oceanic and Planetary Physics
University of Oxford, UK.
tjkv@atm.ox.ac.uk  preferred
From: u9035710@cs.uow.edu.au (Scott Anthony Barnett)
Newsgroups: comp.lang.c
Subject: Registering Fonts with Borland C++ v 3.0
Date: 13 Aug 92 03:29:22 GMT
Organization: Dept of Computer Science, Wollongong University, Australia

Having recently written a prg. that uses graphics functions and fonts
on Borland C++ v3.0 I wish to link the graphics drivers and font files into 
the one executable.  I can do the graphic driver (EGAVGA.BGI) and fonts
prior to v3.0, but the new fonts with v3.0 don't seem to work !!!

Help is appreciated....

-- 
=====================================================================
= Scott Barnett =========== Email : u9035710@wraith.cs.uow.edu.au   =
= 3rd Year Comp. Engineer. == University of Wollongong, Australia   =
===(Such creative flair only to be limited by a 4 line .sig limit)===
Newsgroups: comp.lang.c
From: scott@megadata.mega.oz.au (Scott Humphreys)
Subject: Is "...", instead of ",..." legal ?
Keywords: variable arguments
Organization: Megadata P/L, North Ryde, Sydney, Aust.
Date: Thu, 13 Aug 1992 00:27:17 GMT

In various books describing the expansion to ANSI-C,
one of the differences is described as the inclusion
of the ",..." operator for function prototypes
[ meaning that a variable number of arguments follow-
  e.g. int printf (const char *, ...);  ]

My question is: is this legal : int foo (...);

That is - can I legally declare a function 
with none or many arguments, or does it HAVE to have
at least one argument.

This came up because gcc version 2.2.2 let me do it,
but gave a warning when used with the -pedantic option.
Another tool I used (gnu GCT version 1.3) bombed on this construct.

Thanks for your time - I trust this isn't a FAQ...
[cross-posted to comp.lang.c - my mailer means I have to do it individually].
-- 
Dad to Jill (6), Hugh (3), Rhett (1), ? (find out in Dec).
email:  scott@megadata.mega.oz.au |        /\          _/_ _/_ 
fax:    (Int'l +61) (02) 887-4847 |       /  )  _. ____/   /   
voice:  (Int'l +61) (02) 805-0899 |      /__/__(__(_) (___<__
From: meglan@mayo.edu (Dwight Meglan)
Newsgroups: comp.lang.c
Subject: vector/matrix rpn-like calculator
Date: 14 Aug 92 21:41:08 GMT
Followup-To: comp.lang.c
Organization: Orthopedic Biomechanics/ Mayo Clinic

I am looking for c code for a rpn style calculator which supports
vector and matrix calculations. I have looked with archie and found
source to simple stack based calculators that operate on individual
numbers- all similar to the example in K&R. 

I have a fair idea of how I want to do this but would like to look
over other's efforts if possible. I am kind of using as a model how
ASYST works- I have used for a while now and find its way of working
vectors and matrices to be quite convenient.

If anyone can give me pointers on where to look for source code, it
would be most helpful. 

Thanks, dwight

By the way, I did find a quaternion calculator that used lex/yacc but
I don't really want to try to learn these if I can help it at this
point in time.
Newsgroups: comp.lang.c
From: root@fincomp.raidernet.com (Neal McClain)
Subject: Re: Routine to disable Ctrl-Alt-Del on PC
Organization: Financial Computers Corp., Murfreesboro, TN
Date: Thu, 13 Aug 1992 13:59:12 GMT

In <1992Aug13.032504.8555@cs.uow.edu.au> 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.

Simple:

   1.  Install a 386 based UNIX on said PC.
   2.  Boot UNIX


:-)  Sorry - couldn't resist!


Neal McClain               | Beam me up Scottie, there's no intelligent 
Murfreesboro, Tn           | life down here!   
root@fincomp.raidernet.com | uunet!mjbtn!fincomp!root
From: linden@positive.Eng.Sun.COM (Peter van der Linden)
Newsgroups: comp.lang.c
Subject: Re: Pointer/address reluctance
Date: 18 Aug 92 16:53:02 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: positive

From: sasghm@theseus.unx.sas.com (Gary Merrill)
> 	An address constant in C begins with an ampersand.

Actually, the above statement is not accurate.  Address constants
are also created implicitly, with no ampersand, by the use of an
expression of array or function type.

Even if the statement were accurate, it does not disprove my point
any more than saying that "floating point numbers have a dot".
We have a certain ASCII notation for convenience, but what we are
really talking about is the entity on (abstract if you like)
hardware.

My point is that it doesn't do much good to try to be more abstract
than the ANSI C standard; the ANSI C standard is happy with asides
and references to addresses.   You could be too.


--
linden@eng.sun.com|| P. van der Linden and his uncustomary theories.
Go Giants!! Don't || When solving a "panic" you must first ask yourself what you
stop at Florida...|| were doing that could possibly frighten an operating system
Newsgroups: comp.lang.c
From: pct@RLG.Stanford.EDU (Peter C. Tam)
Subject: Re: INCLUDE file not found
Organization: Research Libraries Group, Inc.
Date: Fri, 14 Aug 1992 00:10:48 GMT


  My config.sys has files=10 but that is still not enough.
  The new-conf.sys under \c600\bin directory has files=20, & that did
  the trick. Thanks for your help.