HDTenEightyP/NetNews huggingface dataset:
From: votava@fndaud.fnal.gov (Margaret Votava)
Newsgroups: comp.lang.c
Subject: Volatile variables and optimization
Date: 15 Oct 92 20:11:15 GMT
Article-I.D.: fnnews.1bkj93INN1m1
Distribution: world
Organization: Fermi National Accelerator Laboratory, Batavia IL
NNTP-Posting-Host: fndaue.fnal.gov

Hi,

	I've got a simple question about the correct behavior of the ANSI
C compiler regarding volatile variables. I have a memory location that I 
simply want to read. I don't want to do anything with the result; it is
just a hardware location that needs to be touched.

	The following piece of code will access the location when compiled
without optimization, but is optimized out when optimization is turned on in 
the compilation command.

	I thought the point of volatile was to *always* fetch the value
from memory.

int junk()
{
	volatile unsigned short *mem_addr;
	mem_addr = (volatile unsigned short *) 0x3000;
	(void) *mem_addr;
}

Thanks in advance for any insight,
Margaret Votava
Fermi National Accelerator Laboratory
votava@fnal.fnal.gov
Newsgroups: comp.lang.c
From: "jeff zeitlin" <jeff.zeitlin@execnet.com>
Newsgroups: comp.lang.c
Subject: algorithm for day-of-week
Date: 11 Oct 92 03:17:28 EST
Reply-To: "jeff zeitlin" <jeff.zeitlin@execnet.com>
Distribution: comp
Organization: Executive Networks Information

    ::>>>if it doesn't, it should, I am certain about the "except if divisible
    ::>>>by 100"  I am not so certain about the second, "un-exception" when
    ::>>>divisible by 400.  can anyone confirm?
    ::>>
    ::>>if 4, but not 10, but if 400, but not 1000, but if 4000... obviously onl
    ::>               ^^                      ^^^^         ^^^^
    ::>I think you really meant " if 4, but not 100, but if 400, but not 10000,
    ::>if 40000....."

    If 4 but not 100 but if 400 but not 4,000 is as far as the
    current implementation of the Gregorian Calendar goes.  This is
    accurate to one day in 20,000 years.  It has been alleged that the
    Soviet Union was using a "corrected" Gregorian calendar that had
    the compensation day (but if 20,000), but since there's at least
    18,000 years before we have to worry, the additional change was
    academic...

  J/
  jeff.zeitlin@execnet.com
  ==================================================================
  Anything I say in this or any communication to this or any medium
  is strictly my own non-authoritative opinion, unless otherwise
  explicitly noted.  Except for myself, or where explicitly noted
  otherwise, I do not speak for any individual or organization.
  ==================================================================

 * OLX 2.2 * Duj tlvoqtaH.  Always trust your instincts.
--
Executive Network Information System  (914) 667-4567
International ILink Host
Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Strings and integer sizes
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 14 Oct 1992 02:49:22 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:

>And despite my reply to Lars, it's not a #define, it was upgraded
>to an inline function in the include file:
>
>inline char *strncpyz(char *s1, const char *s2, int n)
>  { char *s; s = strncpy(s1, s2, n); s1[n] = '\0'; return s; }
>
>less efficent than the #define (especially w/ that local "char *s")
>but safer (I suppose....)

Firstly, this is comp.lang.c, not comp.lang.c++.
(Why do I get the feeling that I am repeating myself?)
Inline functions are NOT standard C.

Secondly, inline functions are NOT less efficient than #define.
(Unless the inline function is too complicated for your dumb compiler to
actually inline.)

-- 
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!
Xref: sparky comp.lang.c:14716 gnu.gcc.help:2285
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c,gnu.gcc.help
Subject: Re: lint
Date: 9 Oct 92 06:03:10 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Followup-To: gnu.gcc.help
Organization: University of Arizona

[follow-ups to gnu.gcc.help, please]

In article <1992Oct7.165412.2404@thyme.jpl.nasa.gov>, kaleb@thyme (Kaleb Keithley) writes:
>In article <herman.718468501@phage> herman@nosc.mil (John W. Herman) writes:
>>
>>Why doesn't the FSF have a lint that works with GCC??
>
>Whatever for?  'gcc -c -Wall -pedantic -traditional' does a much better job
                               ^^^^^^^^
>on K&R1 C than most lints do.  And if you substitute -traditional with
>-ansi, it works on Standard (K&R2 a.k.a. ANSI) C too.

Does the "pedantic" flag really do anything useful?  The documentation we
have for gcc here says

     -pedantic
          Issue all the warnings demanded by strict ANSI standard
          C; reject all programs that use forbidden extensions.
	  [...]
	  There is no reason to use this option; it exists only to
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          satisfy pedants.
	  ^^^^^^^^^^^^^^^

-- 
Dave Schaumann			dave@cs.arizona.edu
Newsgroups: comp.lang.c
From: wilson@glitch.cs.jhu.edu (Dwight Wilson)
Subject: Re: Life, stderr, and everything (was Re: malloc() as a user...)
Organization: The Johns Hopkins University CS Department
Date: Thu, 15 Oct 1992 22:35:07 GMT

In article <1992Oct15.192831.8796@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
[long discussion about errno and malloc]
>
>I have not been interpreting errno after malloc failures,
>although based on Fergus's arguments, I might begin to do so.
>(I note, however, that the Posix standard, at least in section
>B1.4.3 of the 1988 version, does *not* give any more assurances
>for malloc's implementation and failure modes than does X3.159 .)
>
>In spite of my obvious bias, I am not trying to argue one way or
>the other.  There is no one right answer here (i.e. Richard and
>Fergus are never going to convince each other); one has to decide
>based on a program's expected life history which approach is
>preferable.

How about using conditial compilation inside a wrapper function?
Then you can easily use errno if you know the implementation
supports it, and can suppress it if it will result in misleading
error messages.  

-Dwight
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Fast way of counting number of bits =1 in an int.
Keywords: bit operations
Date: 10 Oct 92 12:43:48 GMT
Organization: University of Helsinki

puri@enel.ucalgary.ca (Ruchir Puri) writes:
>Hi there!
>	I was wondering if software pundits out there know of 
>a better way of counting the number of bits=1 in an integer variable.

Check item 17.12 in the FAQ.  (I sent a copy.)

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
From: parker@ccwf.cc.utexas.edu (Bryan Parker)
Newsgroups: comp.lang.c
Subject: Novice pointer/array question & libraries
Keywords: arrays libraries
Date: 8 Oct 92 01:37:50 GMT
Organization: The University of Texas at Austin, Austin TX

I am having trouble using a pointer to an array. I would like to declare the
following:

/* direct VGA screen writing      */
/* Let's assume we're already in 320x200x256  */

typedef unsigned char screenmap[200][320];
screenmap far *vgascr;

vgascr = MK_FP(0xA000, 0);

Now, my question is, how do I go about accessing the elements of vgascr?

I have tried simply,
	*vgascr[y][x] = color;

but this doens't work.  When I use the Inspect option under Turbo C++, it shows
that the array *vgascr is at the appropriate address, that is, A000:0000, but
*vgascr[0][1] is 320 bytes away instead of just one.  Even worse, *vgascr[1][0]
seems to be 320 * 200 bytes away.  Suffice it to say that it is not pointing
where I would like it to!
 
The point of this array is to be able to write directly to the VGA screen. I
have seen this done and it works great in Pascal by declaring a normal array
at ABSOLUTE $A000:0000.  Is this a bad idea?  I mean, would I be better off
accessing the screen differently?  I have written an assembly language 
routine to do just this, but I would also like to be able to do it with the
array. 
 
Methinks that I am declaring the array wrong... that what I think is a pointer
to a two dimensional array is actually something else?  Like an array of 200
pointers to arrays of 320 chars each?  When I zoom in all the way in an Inspect
window, it shows *vgascr[0][0][0] at A000:0000.  :/ 
 
What would be the correct way to declare a single pointer to this array?

Next question... how exactly do I create a library file in Turbo C++???
In my opinion, the manuals provided with the package SUCK.  They go so far
as to say it is possible to compile related routines and functions in seperate
programs and create library files that the main program will call, but don't
explain HOW it is done!  I would like to put my VGA screen functions in a
seperate file, but when I try to compile it I keep getting the "unknown ident-
ifier _main in module c0.asm" or something like that.  How do I tell the
compiler I am creating a library?  (and then I'll need to make a header file,
right?)

Please e-mail me, your help is greatly appreciated.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Union-initialization portability
Date: 8 Oct 92 18:53:13 GMT
Article-I.D.: ulogic.399
Organization: negligable

In article <1992Oct2.174845.28427@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>Yes, a union "provides multiply-typed handles to the same data,"
>which ends up meaning that it does *not* "`cast back' the pointer
>into its proper type."  When you use a union, you take
>responsibility for keeping track of what kind of bit pattern is
>stored.  If you write to one member of a union and then read from
>another, no change of bits occurs, which is why an attempt to do
>so yields behavior that is, in general, undefined.  (Contrariwise,
>when you need to write unportable code which interprets some bits
>as another type, without changing the bits, a union is often the
>way to go.)

You are correct.  Sorry.  If you have a pointer to an int and
a pointer to a long the VALUE will not get translated (cast)
from int to long when you dereference the other pointer.

Mea culpa.

That's what I get for rushing....

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Nobody has ever had a sexual fantasy about being tied
 to a bed and ravished by somebody dressed as a liberal."    -P.J. O'Rourke
From: mxb8@po.CWRU.Edu (Matthew Bakaitis)
Newsgroups: comp.lang.c
Subject: Extended Mem use on an IBM clone using C/C++
Date: 9 Oct 1992 03:49:41 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
Reply-To: mxb8@po.CWRU.Edu (Matthew Bakaitis)
NNTP-Posting-Host: thor.ins.cwru.edu


	Currently, I'm using an IBM clone with 8 meg of extended memory
to do some statistical analysis for some (boring) classes...I decided to
try to use a big sample size, but naturally ran into a problem with making
my arrays larger than allowed than the Turbo C++ 1.0 compiler I'm using.
	I tried to use the command _OvrInitEms and _OvrInitExt given in
the library reference manuals, but I couldn't get either of them to work.

So, two things:

1)  Are there any books out there that are specifically aimed at programming
	in C/C++ that deal with using this memory?
2)  Are the library functions given in the Borland manuals not the thing to
	use?  Are there better PD libraries to use?  etc.

	Notes:
	I am a decent programmer, but it is not my true vocation it seems.
I am competent in programming in T-C++ for an IBM, but that's about the
limit of it.  I _am_ pretty good at this little niche, however.
	I am crossposting this to a few groups, so take note.  The post
is to rec.games.programmer thanks to a note I read about a PBM game that
had four million planets in it.  I figured that equaled either an incredible
amount of disk access (that I would like to avoid) or some hefty memory
use...

Thanks,
Matt
-- 
Matt Bakaitis
mxb8@po.cwru.edu
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.c
Subject: Re: multidimensional arrays as parameters
Date: 14 Oct 92 20:51:03 GMT
Organization: CWI, Amsterdam

In article <behrenss.719056199@hphalle6> behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens) writes:
 > bill@chaos.phys.ualberta.ca (Bill Burris) writes:
 > 
 > >I was wondering how to pass a multidimensional array as a parameter.
 > 
 > Serious suggestion first: Buy a book on C.
Yes indeed, follow it, especially as your solution is wrong.
 > 
 > >Now for a 2D array if I do the following:
 > >void fun2d( int * );
 > >int array2d[10][20];
 > 
 > And how do you think that would work? You tell the compiler that fun2d
 > expects 'int *', and then you pass it 'int **'. You could declare
 > fun2d (int **foo) or fun2d (int *foo[]) or fun2d (int foo[][]). All
 > of these are equivalent, as passed arrays get converted to appropriate
 > pointers, anyway.
The first two are indeed equivalent, but wrong, the third is invalid
(clearly you did not try your suggestions).  Chris Torek can explain
it better, but: the type of array2d is:
	array 10 of array 20 of int
which decays in a parameter position to:
	pointer to array 20 of int.
The first suggestion gives the parameter type:
	pointer to pointer to int
and the second the equivalent parameter type:
	array unspecified of pointer to int
which are different beasts.
So the proper prototypes are the (equivalent) fun2d(int (*foo)[20]) and
fun2d(int foo[][20]).  Note that the 20 is required, probably not what the
original poster wants!  What he probably wants is the original prototype
but he needs to cast array2d in the call:  (int *)array2d.  Which will do
the job.
 > 
 > And now go and buy a book on C :)
Right.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: How does free() work ?
Organization: Sequoia Peripherals, Inc.
Date: Wed, 14 Oct 92 02:57:54 GMT

In article <6BXLsB1w165w@quest.UUCP> srhqla!quest!kdq writes:
>
>    Actually, trying to free NULL usually doesn't hurt.  Most of the
>libraries I looked into check for NULL before they try to free the
>memory: no harm, no foul.  I'm not sure I'd count on it if portability
>were one of my goals, since I'm pretty sure this isn't actually
>mandated behaviour,

It is mandated behavior, i.e., the ANSI standard requires freeing
a NULL pointer to be a no-op. But I still wouldn't count on it
if I were writing portable code --- many pre-ANSI compilers cause
you to die a violent death if you free a NULL pointer.


-- 
Dave Eisen    dkeisen@leland.Stanford.EDU   Sequoia Peripherals: (415) 967-5644
      Incompetent amateurs have given prostitution a bad name.
        --- Camille Paglia in "Madonna II: Venus of the Radio Waves"
From: Eric.Bergman-Terrell@f1.n100.z60.wlink.nl (Eric Bergman-Terrell)
Newsgroups: comp.lang.c
Subject: call graph generator
Date: Tue, 13 Oct 1992 08:52:09 -0100

Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.

In article <12OCT199222565635@rosie.uh.edu> st1n2@rosie.uh.edu (McCoy, Mark) writes:
>I am faced with the following assignment as part of a team project
>for a software engineering class:
>
>-----------------------------------------------------------------------
>The source code of a large software system is usually organized as a set
>of files stored in a single directory.  Each file contains one or more
>seperately compilable program units.  The way these units call one
>another during execution provides an important clue about the working of
>the software system.  Conceptually, this information can be represented
>by a directed graph in which each node represents a subprogram, and 
>each edge represents a possible function or procedure call.  Such a graph
>is called a call graph.
>
>In this project, the task is to produce a call-graph-generator that
>accepts a directory name as input and constructs the call graph of the
>software system contained in that directory.  It is assumed that all
>programs (including the generator and its inputs) are written in C
>under UNIX. 
>-----------------------------------------------------------------------
>
>I know that the above mentioned call grapher is a fairly common development
>tool (I have seen plenty in advertisements but never in person).
>Since this project is fairly open ended as far as required features, a good
>starting point would be to see whats already been done and work from there.
>So..Is there anything anywhere that fits the above description.  preferably
>PD.
>I am also in the process of hunting down an algorithm to solve the problem of
>node placement on the graph.  Any help on either front would be much
>appreciated.
>Thanks in advance
>
>Mark McCoy (st1n2@jetson.uh.edu)

See The C User's Journal, October 1991, pp. 33 - 39 for an article that I
wrote which includes a complete call tree generator for Borland and Microsoft
C.  The program could be easily adapted to other environments.

Terrell


Newsgroups: comp.lang.c
From: card@sybus.com (James Card)
Subject: Re: memory allocation in struct
Keywords: array, struct
Organization: Sybus Corporation, Largo, FL
Date: Thu, 15 Oct 1992 22:16:18 GMT

In article <int177c.719033514@aurora.cc.monash.edu.au> int177c@aurora.cc.monash.edu.au (Jae J Won) writes:
>typedef struct hmm {
>	int value[100];
>} HMM;
>
>HMM a[10];
>
>If I declare something like that, does it allocate memory for all of the
>100 int's or just a pointer to value? I am having prob in that the stack allocation is going mad sometimes. I think it is because of above prob. If it doesn't
>allocate all the 100 int's, then what should I do? Should I have a pointer
>instead and personally malloc it and then access by the array method?

The compiler will try to allocate data memory or stack memory
(depending on where you declare "a".)  Now if you declare it as
an auto variable (stack variable) the compiler will generate
code to allocate stack, but it is up to you to make sure that
the stack that is allocated is actually available.  If you
are using a DOS based compiler, then it is usually a
external variable such as "_stklen" that you need to set
so that your stack is sufficiently large enough for the
largest amount you will be using.

Hope this helps...
jC

-- 
  __/o___~_                 James Card (Firmware Engineer)
 (________|  Nothin' like   Sybus Corporation
   @    @    top down       2300 Tall Pines Dr. Suite 100
             weather...     Largo, Fl  34641  (813) 535-6999
From: ganesh@cs.albany.edu (Ganesh Murugesan)
Newsgroups: comp.lang.c
Subject: Re: Scanf and pointer problem, HEELP!!
Date: 13 Oct 92 23:15:08 GMT
Organization: Computer Science Department, SUNY at Albany, Albany, NY 12222
Originator: ganesh@karp.albany.edu

In article <1992Oct13.212855.12532@jade.tufts.edu> slahiri@jade.tufts.edu (Sandip Lahiri) writes:

> I don't know whether this is a faq, but scanf is screwing me left and
> right (sorry for the language folks, but i am pretty frustated at this
> point). My program does a seg fault if i say this,
> 
> char *nodename;
> 
> scanf("%s",nodename);
>


====>   The problem is you have not allocated space for the String.
      U have allocated space for a Pointer (by the declaration) which
      is 4 bytes , but now as U are reading the string, U are trying
      to overwrite into memroy U process has not been allocated, hence
      the segmentation fault.
      
> I got around the problem by initializing nodename to "", so that
> now i have,
> 
> char *nodename = "";
> 
> scanf("%s", nodename);

====> This must be just a freak, and the run time environment will
catch this sooner or later.
>

> After this I am calling another function, from main() as before,
> 
> int get_node(fptr)
> FILE *fptr;
> {
>  char *nodename, *list = "";
> 
>  printf("Enter nodename: );
>  scanf("%s", nodename);
> 
>  printf("Enter list of nodes: );
>  /* I am using gets to read in the lines from here */


Ganesh
Graduate Student,
Dept. of Computer Science,
SUNY at Albany.

The only thing fault tolerant about the Internet is its users are
tolerant towards its faults.

-- 
The only thing Fault tolerant about the internet is that its
users are willing to tolerate its faults
Newsgroups: comp.lang.c
From: ab2r@quads.uchicago.edu (Marshall Abrams)
Subject: Re: gcc (WHERE TO FIND MSDOS GCC)
Keywords: gcc djgpp msdos
Reply-To: ab2r@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Tue, 13 Oct 1992 16:08:28 GMT

In article <1992Oct13.152120.25783@pony.Ingres.COM> jonm@Ingres.COM (Go ahead... see if I care) writes:
>>>Where can I find gcc for both msdos and a sequent balance?
>> 
>>Someone posted this address recently for the MSDOS version:
>> 
>>	barancle.erc.clarkson.edu
>>	in /pub/msdos/djgpp
>> 
>
>I can't seem to ftp onto this.  Would you have an internet ID?
>
>			barancle.erc.clarkson.edu
>
>Jon M

In the posting I saw, the following number was included after
"barancle.erc.clarkson.edu":

		128.153.28.12

Is that an Internet ID?

Marshall Abrams
Newsgroups: comp.lang.c
From: Karen.Denbleyker@bbs.oit.unc.edu (Karen Denbleyker)
Subject: Re: FAQ: Book for learning C.
Organization: Extended Bulletin Board Service
Date: Sat, 10 Oct 1992 01:56:43 GMT

In article <1992Oct8.212858.8933@nwnexus.WA.COM> prangba@halcyon.com (Bruce Prang) writes:
>I have a friend that is in the proceses of learning C. He is using an
>MS-DOS box to learn but he will be doing some of the programming on a
>Unix (AT&T SysV) box. He asked me for a recomandation but I didn't use a
>book in learning so I couldn't help him. How bout any of you fine folks?
>
>The book would ideally teach ANSI C with notes of perhaps how some of
>the MS-DOS compilers (MS, Borland, Zortech) differ. He's not looking for
>reference book, he has one of those. More of a real life kinda thing.
>
>
I'm using "C by Dissection  The Essentials of C Programming, 2nd Ed by
Al Kelley and Ira Pohl.  It is primarily ANSI C but it does discuss
the differences between DOS and UNIX based systems.  You might want to
take a look at it.  I'm just beginning to learn C and it seems to be
pretty well written and understandable.


--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80
Newsgroups: comp.lang.c
From: oyakea@warren1a.its.rpi.edu (Amalaye Oyake)
Subject: GRAPHICS LIBRARIES FOR SUN OR AIX
Reply-To: oyakea@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Thu, 8 Oct 1992 02:09:07 GMT

 I am a user of Sun IPC's and IBM xstation and RS 6000 machines. I write text only programs in C using the gnu line of compilers. I would like to do graphics please send ftp sites of graphics libraries for C.

Thank you.
Newsgroups: comp.lang.c
From: M14465@mwvm.mitre.org
Subject: Help with Windows C and DLLs
Organization: The MITRE Corporation, McLean VA 22102
Date: Thu, 15 Oct 1992 11:30:55 GMT

Looking for help with Dynamic Link Library (DLL), in particular, calling
a function in one DLL (call it A.DLL) from another DLL (call it B.DLL).
I'm having problems with getting General Protection Faults when I do so.
Borland has sent me on the Turbo Debugger path (which I now must read
up on before I can use it).  However, if anybody knows any tricks to
writing a DLL of this sort, I would appreciate hearing from you.  Also
note that I am calling the function in B.DLL from a Word Basic routine.
Although arguments are passed in the argument list, none of them are
used as yet.  I'm just trying to get the function in A.DLL to work so,
rather than use those arguments, I'm hard coding the values I send to
the function in A.DLL.  It's interesting to note, too, that calling this
function worked fine as a simple Windows Application (.EXE) and it
actually works now in the DLL form except for the pesky GPF.
 
Thanks in advance!
Xref: sparky comp.lang.c:15052 comp.lang.fortran:3995 comp.lang.pascal:6021