HDTenEightyP/NetNews huggingface dataset:
From: murphy@mips.com (Mike Murphy)
Newsgroups: comp.lang.c
Subject: Re: 64 bit pointers?
Date: 10 Apr 1992 21:30:50 GMT
Organization: MIPS Computer Systems, Sunnyvale, California
NNTP-Posting-Host: ada.mips.com

In article <BMH3CK.6Kr@world.std.com> mynzy@world.std.com (Peter H Jurgensen) writes:
>32 bit pointers have been normal for a long time (except for old PCs).
>Now that the R4000 is out, the Alpha is comming, Cray is making a PC ;-), etc.
>what are the implications for pointer sizes? I have hand tuned structures
>containing pointers to use strict alignment without wasted space, but what
>will happen on a 64 bit machine? How does one write portable code that is 
>efficient relative to pointer size? This isn't a FAQ, but it should be.

Most vendors of 64-bit systems are planning on having a compatibility
mode of some sorts, where pointers remain 32 bits, so that old software
can compile and run "as is".  So if you don't need 64-bit addresses,
you don't need to use them.  But if you do want to take advantage of
64-bit addresses, then you may have to adjust some of your structures.
Note that depending on the implementation, other types like "long"
may also become 64-bits when pointers become 64 bits.  Another factor
to beware of is that 64-bit fields will want 64-bit alignment.
A short,short,void* sequence of structure fields will likely get
an extra padding before the pointer in the 64-bit world.
--mike
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: 486-50 Mhz, getting too HOT????
Date: 9 Apr 92 16:27:21 EDT

u8930217@golum.riv.csu.edu.au (Mr Chang) writes:
>Hardware wizards,
>     Has anyone out there own a 486-50Mhz ISA Machine??
>     Have you experience any over heating problem, especially in a
>non air-conditioned room?? 
>     How is it performance compared to any other low-end Unix
>Workstations??

I have been over and over my copies of the ANSI C standard, K&R I and II,
and a handy copy of Harbison and Steele.

I have yet to find any mention of overheating processors, 486-50 or otherwise,
in any of these references.

Perhaps you might consider, in future, not posting to completely random
groups?

Perhaps sci.aquaria would have been a good group, however, since they could
at least tell you how large an aquarium would be required to dunk your PC in.
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: atexit_t ???
Keywords: Turbo C
Organization: TauMetric Corporation
Date: Fri, 10 Apr 1992 15:48:18 GMT

valley@gsbsun.uchicago.edu (Doug Dougherty) writes:

>>There is no "atexit_t" in ANSI C, and since that name is in the user's
>>namespace, an ANSI C implementation must not define it.

>>The Synopsis for atexit() in the standard is:

>>	#include <stdlib.h>
>>	int atexit(void (*func)(void));

>I have gotten many conflicting responses to my query.  Many claim it is
>an ANSIism, others, like you, claim it is not.

That is perhaps because there are two parts to this.

1.  atexit() is an ISO/ANSI C standard function.

2.  atexit_t is not part of the ISO/ANSI C standard, and this identifier
    is therefore reserved to the programmer as far as that standard is
    concerned.  (POSIX or other standards may impose other restrictions
    on programmer names.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c,comp.std.c,comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: "long long" for 64 bits
Organization: Xenix Support, FICC
Date: Wed, 15 Apr 1992 14:00:55 GMT

In article <1992Apr14.164643.1057@thinkage.on.ca> atbowler@thinkage.on.ca (Alan Bowler) writes:
> In article <id.45VO.ZFD@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
> >Then have appropriate virtual typedefs (controlled by command line switches)
> >that define int and long in terms of these. That will allow you to accomodate
> >all sorts of broken programs AND allow access to any integer size. You can
> >also allow "long long" to be set to one of these.

> "Add a compile option" is always a nice glib answer.  Unfortunately,
> it does not really solve many problems.

I really wasn't meaning to be glib. I maintain, on an ongoing basis, code
that has to remain compatible with 16- and 32- bit ints and big- and little-
endian architectures. I'm basing this suggestion on that experience.

> Besides the particular code
> module being compiled there will also be a large library of compiled
> code and a number of include files with structs an unions.

Which should be defined in terms of known types. In the worst case you
will have to maintain two versions of the library (not "several" versions,
unless your vendor is maliciously stupid... at worst I can see a use for
three: 32 bit int + 32 bit pointer, 32 bit int + 64 bit pointer, and 64
bit int + 64 bit pointer. Personally I wouldn't bother implementing a
separate runtime for the 32+64 case, not with ANSI compilers). I have to
maintain four versions of all *my* libraries on Xenix-286, and it's not that
big a deal. I certainly wouldn't expect it to be an undue burden on a vendor.
Just make sure you've got your <sys/types.h> straight (that is, you make
your system include files depend on the explicitly sized types: int32,
int16, unsigned int64, ...).

The biggest problem I have comes from not being able to avoid the segments:
our compiler doesn't support the "huge" model. That wouldn't be a problem
for the 64-bit world (barring major brain damage on the part of the vendors).
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: printf() questions
Organization: D'Arcy Cain Consulting
Date: Tue, 7 Apr 1992 19:29:24 GMT

toma@swsrv1.cirr.com (Tom Armistead) writes:
>In article <22918.29da2dd0@amherst.edu> pfcouvares@amherst.edu writes:
>>2) If you indicate a field, and the string turns out to be longer, printf will
>>print the entire string anyway. Is there any way to make printf truncate the
>>string so that the field is absolute even if the string is longer?
>For your 2nd question: You can put a period before the length specifier
>to limit the size of the output;
>    printf( "%.-25s", name );
>	or
>    printf( "%-.25s", name );

Almost.  He wanted an absolute width.  This gives him a maximum width.  What
he wants is:
    printf( "%.-25.25s", name );
which will use no more and no less than 25 characters.

>You could answer both questions with;
>    printf( ".-*s", NAME_SIZE, name );
  printf("%-*.*", NAME_SIZE, NAME_SIZE, name);
or
  printf("%*.*", -NAME_SIZE, NAME_SIZE, name);

-- 
D'Arcy J.M. Cain (darcy@druid)     |
D'Arcy Cain Consulting             |   There's no government
Toronto, Ontario, Canada           |   like no government!
+1 416 424 2871          DoD#0082  |
Newsgroups: comp.lang.c,comp.std.c,comp.arch
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: "long long" for 64 bits
Organization: Sequoia Peripherals, Inc.
Date: Fri, 17 Apr 92 05:19:42 GMT

In article <1TA02R9@cdis-1.compu.com> tanner@cdis-1.compu.com (Dr. T. Andrews) writes:
>
>The other is that, in this age when lint(1) should no  longer  be
>considered  a  novelty,  no one else uses it.  Not only does lint
>generally complain about size mis-matches in function calls,  but
>a  clever  one  such as the one we use here even notices when you
>use the wrong format in the printf(3) functions.

The lint on my system doesn't even understand prototypes. It would 
barf on just about every line of code I write. People used lint
a whole lot more before ANSI C came out.



-- 
Dave Eisen    dkeisen@leland.Stanford.EDU   Sequoia Peripherals: (415) 967-5644
      There's something in my library to offend everybody.
        --- Washington Coalition Against Censorship
From: kgs@cnmss.tredydev.unisys.com (Ken Salter)
Newsgroups: comp.lang.c
Subject: 64 bit integers
Date: 15 Apr 92 17:49:38 GMT
Organization: Unisys Corp.


Has anyone used, or even heard of, a library that supports double
precision (8 byte) integers, preferably in a Unix System V Release 4.0,
ANSI C environment?


			Ken Salter
From: volpe@bart.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Re: float rounding code
Date: 6 Apr 92 16:30:48 GMT
Reply-To: volpe@bart.crd.ge.com (Christopher R Volpe)
Organization: GE Corporate R&D Center

In article <1992Apr4.053022.10198@aplcen.apl.jhu.edu>,
jclark@aplcen.apl.jhu.edu (S Clark james hawkin [A[A[A[B[Bx) writes:
|>
|>> dvar = (float)(long)(dvar * 10000) / 10000;
|>
|>I tried that and it came out like 15.9999899999 and the if () test
|>came out true.

Right idea, but needs some more parens:

dvar = ((float)((long)(dvar * 10000))) / 10000;

We want to truncate the product first (via the long cast), then convert
the long back to float (so that the next division will be a floating
division) and then do the divide.

==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: volpe@bart.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 10 Apr 92 21:36:35 GMT
Reply-To: volpe@bart.crd.ge.com (Christopher R Volpe)
Organization: GE Corporate R&D Center

In article <kub3trINNgo8@news.bbn.com>, jclesius@bbn.com (Jeff Clesius) writes:
|>volpe@bart.crd.ge.com (Christopher R Volpe) writes:
|>
|>>C, whether it be ANSI or pre-ANSI, has always required that all parameters,
|>                                        ^^^^^^
|>>structures or otherwise, be passed by value.
|>
|>
|>Not ALWAYS!!!

Yes ALWAYS!!!

|>
|>To quote 'The C Programming Language', K&R, copyright 1978, pg 121:
|>
|>  "This implies that structures may not be assigned to or copied as a unit,
|>   and that they can not be passed to or returned from functions. (These
|>   restrictions will be removed in forth-coming versions.)"
|>

Irrelevant. Note that I did not claim that structures have always been able
to be passed as parameters. I said that all parameters are passed by value.
This is true regardless of whether or not structures are allowed to be passed
at all on the implementation you're dealing with.

==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: Register declaration
Keywords: ambiguity,register,declarations
Date: 7 Apr 92 15:55:30 EDT

bodo@clipper.ingr.com (Bodo Parady) writes:
>A question has arisen regarding the use of the register declaration. 
>Two interpretations of the following statement are possible:
>	register float *x;

The answer is that "register" is a storage-class specifier, and therefore
affects the storage-class of the object named.

"x" is a pointer to a float, and may or may not be contained in a handy piece
of fast storage.

>Another example could be offered:
>	volatile int *x;

The answer is that "volatile" is a type qualifier.

Your declaration says that x is a pointer to a volatile int.

Getting to the heart of your actual problem, the answer is that nothing in
C avoids "the aliasing problem".  Draft ANSI C briefly had a "noalias" keyword,
whose properties no one was really quite sure of, so it disappeared quickly
(besides, Dennis said "``noalias'' must go.  This is non-negotiable." :-).

I gather the "Numerical C Extensions Group" is probably still wrestling with
this tarpit.  Or possibly not.  Currently, anyway, C does not replace FORTRAN
in all possible applications.  Somehow, I'm not surprised.
From: WHIPPLE@RCHVMV.VNET.IBM.COM ("Weldon L. Whipple")
Newsgroups: comp.lang.c
Subject: 128 bit pointers (re: 64 bit pointers?)
Date: 13 Apr 92 13:37:58 GMT
Reply-To: whipple@rchvmv.VNET.IBM.COM

IBM's AS/400 (and its predecessor the System/38) has used 128-bit pointers
from the beginning.  When programming in C/400, I always prototype every
function before it is called.  Otherwise, I invariably run up against
alignment problems.  I can imagine similar problems with 64-bit pointers.

As some have mentioned, there are times when (depending on the sequence of
declarations) the compiler adds extra padding before pointer variables, in
order to ensure correct alignment.

-- Weldon
From: bwc@waikato.ac.nz (Ug!)
Newsgroups: comp.lang.c
Subject: Initialisation code in ANSI C.
Date: 14 Apr 92 13:42:59 +1200
Organization: Vooniersity fo Kaiwato

Hi folks,

A quick question to some kindhearted soul out there, if I may...

Is it possible to have automatic start-up code for a module in C?  Termination
code I can do by using atexit(), but what about where I have a module which
needs to set up before anything else is done?

What I am doing at the moment is explicitly calling the initialisation code
from the main program (i.e. main()), but I would like to have it done
automagically (this after forgetting to do it once and watching everything
go splat!).

I'm using GCC on Sun Sparcs, but I want to restrict myself to reasonably
portable ANSI C.

Thanks in advance,

Bruce Cassidy
University of Waikato
New Zealand
From: volpe@bart.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: a reading from keyboard
Date: 13 Apr 92 18:56:20 GMT
Reply-To: volpe@bart.crd.ge.com (Christopher R Volpe)
Distribution: na
Organization: GE Corporate R&D Center

In article <92101.000901ACPS7081@RyeVm.Ryerson.Ca>,
ACPS7081@RyeVm.Ryerson.Ca writes:
|>
|>Hi
|>I would like to know how can I read from keyboard without using return
|>key.
|>
|>
|>                                                 Thanks for your attention!

Anyone think we should have a Super-Frequently Asked Questions list 
sent out each morning? Perhaps a new group: comp.lang.c.reading_from_the_\
keyboard_without_using_return.

Just kidding. :-)       
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.lang.c
From: alan@bob.sal.wisc.edu (Alan Watson)
Subject: Re: Initialisation code in ANSI C.
Organization: Space Astronomy Lab, Madison, WI
Date: Wed, 15 Apr 1992 03:40:30 GMT

The comment was made that is is too expensive to check that the screen
had been initialized everytime you need to write a single pixel.  But
because C doesn't supply foolproof initialization routines, you would 
have to check each time anyway.  Either that or allow your routines to
possibly make errors which are difficult to track down.  It looks like
you have a choice of good software, fast software, or a redesign.
Newsgroups: comp.lang.c
From: sgccwjf@citec.oz.au (Warwick Faint)
Subject: Wanted: Graph ADT source in C
Organization: CITEC
Date: Thu, 16 Apr 1992 05:02:36 GMT

I am trying to get ahold of source for an ADT in C which will allow me to use
directed graphs.  This is for a commercial application so it must be 
public-domain.

I need the following functions

insertnode, insertedge, deletenode, delteedge, retrieve, update, findnode,
findedge, currentnode, currentedge, create, clear.

Could someone post it, e-mail it, or tell me an Anonymous FTP site where I
can get ahold of it.

Thanks in advance.
Dean Povey.
From: volpe@bart.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: C socket programming
Date: 9 Apr 92 14:30:31 GMT
Reply-To: volpe@bart.crd.ge.com (Christopher R Volpe)
Organization: GE Corporate R&D Center

Email bounced, so I'm posting. Please forgive the inappropriate post.

In article <1992Apr9.065851.4778@helios.physics.utoronto.ca> you write:
|>Hello,
|>
|>   I have just one question (which is VITAL for my project):
|>
|>   How can I mark accept(2) non-blocking?  The man pages suggest that it is
|>possible but don't have anything on how to do so.
|>
|>   A quick reply will be greatly appreciated.  Thanks!
|>
|>---
|>Rudy Amid  amid@ecf.toronto.edu                                            /\
|>   //      a378amid,a318amid,a209amid@cdf.toronto.edu                 
(//\\)
|>  //
|>\X/     "This world needs its dreamers. May they never wake up."
-Prefab Sprout
              
Wrong newsgroup.

There is no such thing as "C socket programming". Sockets don't exist in
C. They are a unix concept. Try posting to comp.unix.programmer.

==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Xref: sparky comp.lang.c:7418 comp.std.c:1775
From: furballs@sequent.com
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: long long long long long madness
Date: 9 Apr 92 19:42:43 GMT
Article-I.D.: sequent.1992Apr9.194243.4748
Organization: Sequent Computer Systems, Inc.

In article <1992Apr5.190707.20122@wyvern.twuug.com> alpha@wyvern.twuug.com (Joe Wright) writes:
>Obviously we don't really want to add new keywords to the
>language just to solve an otherwise machine-related problem.
>Why not compiler directives to tell it how wide we want
>the standard types to be?  Something like this:
>
>#define sizeof(long int) 8  /* Eight units of sizeof(char) */ 
>
>A 'conforming' compiler will note the keywords and, if it can,
>do what we want from then on.  If we write such a compiler, we
>can use:
>
>#define sizeof(char) 1  /* The default, of course */
>#define sizeof(short int) 2
>#define sizeof(int) 4
>#define sizeof(long int) 8
>
>Such a compiler could produce code which would provide 32-bit ints
>and 64-bit longs on any machine, 8088, PDP-11, VAX, Sparc, R4000 or
>whatever.  Let the programmer decide the width of objects.  Let the
>compiler figure out how to do it most efficiently on a given machine.
>-- 
>Joe Wright  alpha@wyvern.twuug.com    

This is the first piece of good sense on this thread in a while
since the #pragma suggestion. The biggest problem I have seen is
that most of this conversation is down in the weeds instead of at
the 10,000 foot level surverying the big picture.

The whole idea behind data types, in my understanding, is to
provide a convienient method to compartmentalize small details and
to build large structures and objects from a machine independant
foundation.

The minute you start forcing all data types to conform to a machine
architecture, you have just antiquated the usefulness of the
compiler. There is *NO* such thing as a truly portable C or C++
compiler. Every vendor gives a twist to theirs to give it a new
marketing feature the others don't have. No two compilers generate
exactly the same assembly level output, which is actually more
important than the idiocy of arguing how long is long.

It is possible to write pure vanilla C code that will run on a vast
majority of systems without choking, but the performance and
features are miserable. This is why people optimize for their
particular need or application or their machine.

What I have done sucessfully in the past is similar to what has
been suggested above, except I plant an anchor on a specific data
type, such as char, and define all others relative to that data
type. For each machine, the anchor may more may not change size as
need be, or I may change the defined size of one of the other data
types to conform to my needs. I now have code that is ANSI
compliant, will compile on any machine I have previously defind,
and will work without modification, assuming I did my homework and
abstracted properly all machine and environment dependancies to a
VM library layer.

It is a bit more work, but I can tell you from experience, the code
holds up on its own for quite a long time.

The morale of this tale is:

Don't force people into using an unnecesary detail, when the
generality will do just fine...
From: alan@bob.sal.wisc.edu (Alan Watson)
Newsgroups: comp.lang.c
Subject: Re: popen
Keywords: popen
Date: 13 Apr 92 17:32:33 GMT
Followup-To: comp.unix.programmer
Organization: Space Astronomy Lab, Madison, WI

In article <1992Apr13.140857.13271@cbnewsm.cb.att.com> eknowles@cbnewsm.cb.att.com (edmund.knowles) writes:
>what happens if popen succeeds but my shell command fails?
>How can I get the exit code into my program?

This is not a C question.  I have redirected follow-ups.

However, on my Unix system, the return code from the pipe 
is returned by pclose.  Check your man pages.
From: eric@pencom.com
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 13 Apr 92 13:15:05 GMT
Organization: Pencom Software

In article <kub3trINNgo8@news.bbn.com> jclesius@bbn.com (Jeff Clesius) writes:
> volpe@bart.crd.ge.com (Christopher R Volpe) writes:
> 
> >C, whether it be ANSI or pre-ANSI, has always required that all parameters,
>                                         ^^^^^^
> >structures or otherwise, be passed by value.
> 
> 
> Not ALWAYS!!!
> 
> To quote 'The C Programming Language', K&R, copyright 1978, pg 121:
> 
>   "This implies that structures may not be assigned to or copied as a unit,
>    and that they can not be passed to or returned from functions. (These
>    restrictions will be removed in forth-coming versions.)"

This has nothing to do with the fact as to whether ALL
parameters are pass by value.  They are and always have been.
The quote implies that whole structures were not able to be passed, period.
You were forced to pass a pointer.  That restriction has, of course, since
been removed.
From: matt.johnson@ehbbs.hou.tx.us (Matt Johnson) 
Newsgroups: comp.lang.c
Subject: Re: Is the address of a g
Date: 15 Apr 92 10:57:00 GMT
Distribution: world
Organization: Ed Hopper's BBS - Houston, TX - 713-997-7575
Reply-To: matt.johnson@ehbbs.hou.tx.us (Matt Johnson) 

 On 04-14-92 STEVE CLAMAGE wrote to ALL... 
 
 SC> matt.johnson@ehbbs.hou.tx.us (Matt Johnson)  writes: 
 SC> >  Sorry Steve, but with relocateable code, there is no way that the 
 SC> compiler  
 SC> >  could know the address of a variable.	For example, using a segmented  
 SC> >  architecture, the offset of the variable would be constant - but the  
 SC> >  segment would be known only at runtime.	With most of today's 
 SC> computers  
 SC> >  able to run several programs at once, how could the compiler of a 
 SC> given  
 SC> >  program know what the address of any variable would be for certain 
 SC> before  
 SC> >  the program runs?  
 SC>  
 SC> The address of a static variable might more properly be described as a 
 SC> link-time or load-time constant, rather than a run-time constant.  That 
 SC> is, the address of such an object does not change once the program has 
 SC> been loaded into memory and begun execution*.  In the contexts in which 
 SC> an address constant is allowed, this is sufficient.  In other contexts, 
 SC> the results of using address constants are undefined. 
 SC> 
		 Mere semantics.	You just described a run-time constant. 
 
... OFFLINE 1.36 * To correct the problem, delete your Config.Sys and reboot...
Newsgroups: comp.lang.c
Subject: question: making archie my friend?
From: eburk@russian.sfsu.edu (Eli K. Burk)
Date: 14 Apr 92 16:55:47 PDT

Is there a site that has information about C available for anonymous
ftp. By information I mean like would be found in a C book (i.e.
how to use malloc, etc.) 

How can i best find such information using archie?

eli
Newsgroups: comp.lang.c