HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: string representation (was: SPAM SPAM SPAM SPAM)
Organization: TauMetric Corporation
Date: Tue, 14 Apr 1992 17:36:45 GMT

dwh@vaxeline.ftp.com (David W. Hamaker) writes:

|I'd love for the compiler
|to be able to generate my "favorite string format of the week" for the
|stuff I put in double quotes.  If my "ultimate string package" ends up
|munging string constants into my format at run time, it wipes out some of
|my vaunted efficiency gains.

|I can imagine a preprocessor directive (#strings...#endstr) that could be
|used in my "mystrings.h" header that would allow a function written in C
|to be put off to the side for the compiler to compile and then call when
|compiling the rest of the program.  I don't know if this is a quality idea,
|but it is a thought.

You can get the effect you want in C++ by defining a string class.
You can choose any representation you like for efficiency, and use
inline functions for more speed.  You can convert to and from
array-of-char automatically.

Asking for user-supplied functions to be called by the compiler to
instantiate a type is unlikely to be granted by a compiler vendor.
(Of course, you could always modify the Gnu C compiler ...)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: matt.johnson@ehbbs.hou.tx.us (Matt Johnson) 
Newsgroups: comp.lang.c
Subject: Redirecting output
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 JOHN  NESTORIAK wrote to ALL... 
 
 J > I have a program which at various points spits stuff out using printf.  
 J > Of 
 J > course when we got the second part of the project we were told that we 
 J > need 
 J > to spit it out to a file.  Is there a way that I can redirect stdout to 
 J > a  
 J > file from within the program?  I need to send it to one of 4 different 
 J > files 
 J > depending on which of 4 child processes creates the output.  I tried: 
 J >    output = fopen("out1","w"); 
 J >    stdout = output; 
 J > But the compiler barfs saying that stdout is an illegal LHS.  What to 
 J > do? 
 J >  
 J > John 
 J >  
	 Hi, John. 
	 stdout is a macro.  It expands to the address of a global data structure. 
	 So, you can't reassign it like that.  What you can do, however, is use 
	 something like 
		 FILE * OutPtr = stdout; 
 
		 if (PrintToFile) 
			 OutPtr = fopen(FileStr, "w"); 
 
	 then, use fprintf(OutPtr,...). 
 
... OFFLINE 1.36 * To correct the problem, delete your Config.Sys and reboot... 

Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Register declaration
Keywords: ambiguity,register,declarations
Organization: D'Arcy Cain Consulting
Date: Thu, 9 Apr 1992 16:27:07 GMT

bodo@clipper.ingr.com (Bodo Parady) writes:
>        register float *x;     is the same as:     (register float)*x
>Or:
>        register float *x      is the same as:     (float)*(register x)

Since you can't compute the address of a register variable (footnote 58
to 3.5.1) then the above must refer to the pointer being the register
variable (that is, x is a register variable that points to a float.)

>The context of the "register" dilemma is the following code fragement: 
>
>>     register float *x, *y, *z, *end_z;
>The problem for any optimizer is that the addressess (x, y, z, send_z)
>can be ambiguous (for example z could equal x, etc).  Does "register" 
>signify that the addresses x,y,z, and send_z are disambiguated?

If z and x are equal (point to the same location) and the optimizer can
determine from the code that this is necessarily so then it can collapse
them to a single variable.  If this causes any effect in your program then
the optimizer is broken.  The existence of the register storage-class
specifier is irrelevant.

You also mentioned volatile.  Note that this is a type qualifier, not a
storage-class specifier.  In this case it can refer to the object
pointed to by a variable.

-- 
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  |
From: jmh@cs.arizona.edu (John M. Hughes)
Newsgroups: comp.lang.c
Subject: Re: Help needed with Linking
Date: 9 Apr 92 03:18:37 GMT
Organization: U of Arizona CS Dept, Tucson

In article <1992Apr8.164948.12547@gmuvax2.gmu.edu> kdontas@gmuvax2.gmu.edu (Kejitan Dontas) writes:
>	    I'm currently trying to link CLIPS 5.0 with my own C source
>code, and am having difficulties.  I am using Borland C++ 2.0, but
>writing regular C. I have one C source file, and the CLIPS library which
>consists of 68 C object files.  Everything compiles, but during linking,
>I get 47 error messages of the form:
>
>	'Linker Error : SEGMENT _TEXT exceeds 64K' 
>
>	    This line appears for 47 of the 68 object files in the
>library.  I don't believe this is a problem in the library as the files
>in it were written by the government (hmm.....) not me.
(that's an interesting assumption :)
[remainder deleted]

From what I've learned about programming on PC's (and from the Borland
manuals), no single text (code) or data object may exceed 64K bytes. The
segmented architecture of Intel's iAPX86 family is the reason. You can,
however, have many smaller text segments, one per object. Examine your
objects and see if you can whittle down the ones that are causing the
problems.
Newsgroups: comp.lang.c
From: rankin@eql.caltech.edu (Pat Rankin)
Subject: Re: Vax C problem
Summary:  next time try comp.os.vms
News-Software: VAX/VMS VNEWS 1.41    
Keywords: VMS VAXC
Organization: California Institute of Technology
Date: Sat, 11 Apr 1992 04:37:00 GMT

In article <10APR199213480143@aardvark.ucs.uoknor.edu>, rkohli@aardvark.ucs.uoknor.edu (I ain't broke, but I'm badly bent) writes...
>   I have tried to figure out this problem but I don't seem to find a solution
>to it. Could someone help me figure it out.

     I'd suggest starting with CC/LIST/SHOW=EXPANSION.  The debugger
would be worthwhile to try to...

>[...]
>quadword convt_ascii_bin(char *as_tim)
>{ 
>  char *as__temp;
>  $DESCRIPTOR(as_tim_desc, as_tim);
>  $DESCRIPTOR(as_tim_desc_temp, as__temp);

     The $DESCRIPTOR() macro requires a string buffer for its second
argument, not a pointer.  It uses (sizeof arg - 1) to fill in the length
field of the string descriptor structure.  A compiler listing would
reveal that, even if you've never looked at the contents of <descrip.h>.
'as__temp' should be declared as char [24] and you'll need to use
strlen() to set the proper length 'as_tim_desc'.

		Pat Rankin, rankin@eql.caltech.edu
From: brianm@cc.gatech.edu (Brian N. Miller)
Newsgroups: comp.lang.c
Subject: Re: Binary mode stdin
Date: 8 Apr 92 14:03:54 GMT
Reply-To: brianm@cc.gatech.edu (Brian N. Miller)
Organization: Georgia Institute of Technology

In article <1992Apr6.184301.14272@klaava.Helsinki.FI>, wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
|> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
|> >I am trying to read stdin as a binary, rather than text, file. 

If you were using a real OS, like UNIX, text and binary IO are indistinguishable.
Still...
 
|> The problem with freopen is that it needs a filename which it opens, and
|> there needn't be any for stdin.  Even when there is, it is not
|> necessarily possible to get it.

Often in UNIX:  Get the process's tty name.  Or determine the file name
                 of the process group's console IO port.

   For MS-DOS:  When in doubt, use BIOS calls.  RT(F)M.   
 

|> >Ideally, the result would be ANSI or K&R compatible,

        C doesn't define IO. _____/        \______ Never.
-- 
     |
   \ | / 
Brian Miller 
            (brianm@cc.gatech.edu)
   --*--
    /|\
     |
    \|/       
Newsgroups: comp.lang.c,alt.flame
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Interpreting Escape Sequences
Followup-To: alt.flame
Organization: D'Arcy Cain Consulting
Date: Thu, 16 Apr 1992 17:50:31 GMT

andy@ian.stx.com (Andy Moore) writes:
>No thanks at all for the many unsolicited comments, critiques, and
>advice on C programming and style in general.  I needed a specific
>answer to a specific question/problem.  I did not ask for a tutorial
>on C, nor for anyone's opinion on my code...  Some specifics:

[ specifics showing evidence of a desire to be helpful deleted ]

>Yes yes yes, I realize all that.  My example program wasn't a *real*
>program; it was a short blurb to get to the specific problem.

So this gives you the right to flame everyone for trying to help?

>Eat my shorts.  Believe it or not, some of us don't *like* C, and some

Where the hell do you get off with this attitude?  You ask a newbie
question and instead of toasting you people try to help you.  They do
not deserve to be treated with the contempt that you have shown.  So
they gave you more help than you needed.  So what.  Purchase a clue
real soon will you.

>of us write real code in the Real World (tm) and don't give a rat's
>about being 'fully correct'.

Not even your customers??????

><flame mode off>  Just my opinions.  In spite of the previous tone used,
>I do appreciate the help many of you have given me.

You sure have a funny way of showing it.

>p.s. By the way, I did in fact check the FAQ carefully before posting...

My mistake.  It's OK to be an asshole then.

Followups to alt.flame.

-- 
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
From: steve@taumet.com (Steve Clamage)
Subject: Re: long long long long long madness
Organization: TauMetric Corporation
Date: Tue, 14 Apr 1992 17:32:02 GMT

hendrik@vedge.UUCP (Hendrik Boom) writes:

>ANSI already has syntax like this in bitfields.
>It looks like
>	int x:64;
>	float y:256;

Well, not exactly.

In Standard C, bitfields must be some flavor of type 'int':
plain/signed/unsigned/const/volatile (but not char/short/long).
Furthermore, the number of bits specified must not be more than
the number of bits in the specified type.

So 'int x:64' is allowed only if type int has at least 64 bits,
and 'float' is not allowed for a bitfield.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c,comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: C standardisation issues for wide machines (was Re: SPAM ...)
Organization: Xenix Support, FICC
Date: Tue, 7 Apr 1992 14:04:17 GMT

I said, referring to an idea for an operand macro mechanism (like #define,
but working on operators depending on their arguments).
>    Doesn't G++ effectively let you do this with inline assembly by creating
>    a new class?

In article <*n5H-qrj6@cs.psu.edu> schwartz@roke.cs.psu.edu (Scott Schwartz) writes:
> To an extent. Many compilers (g++2.0 on sparc, for example) will only
> pass structs on the stack, rather than in registers.  That kills
> efficiency.

I dare say it would.

But does it even do this when expanding code inline?
-- 
-- Peter da Silva,  Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"
Newsgroups: comp.lang.c
From: dougm@rice.edu (Doug Moore)
Subject: Re: Returning the highest bit set in a long
Originator: dougm@cs.rice.edu
Reply-To: dougm@rice.edu (Doug Moore)
Organization: Rice University
Date: Thu, 16 Apr 1992 05:10:17 GMT


In article <9348@baird.cs.strath.ac.uk>, gor@cs.strath.ac.uk (Gordon Russell) writes:
|> 
|>    I am hoping that someone out there has an algorithm for calculating
|> the highest bit set within a long, in terms of its bit position.

And like many others, I offer my favorite version of this code:
(for 32-bit longs)

unsigned long lg(unsigned long x)
{
  long pair[2];
  pair[0] = 0;
  pair[1] = 32;
  long m;
  m = (pair[0]+pair[1]) >> 1;
  pair[x < (1 << m)] = m;
  m = (pair[0]+pair[1]) >> 1;
  pair[x < (1 << m)] = m;
  m = (pair[0]+pair[1]) >> 1;
  pair[x < (1 << m)] = m;
  m = (pair[0]+pair[1]) >> 1;
  pair[x < (1 << m)] = m;
  m = (pair[0]+pair[1]) >> 1;
  pair[x < (1 << m)] = m;
  return pair[0];
}

Thank you for your patience in reading yet another one.

Doug Moore
(dougm@cs.rice.edu)
From: rcs76179@zach.fit.edu (Adnan Zejnilovic / ADVISOR M. Schneider)
Newsgroups: comp.lang.c
Subject: Help!Graphics screen print routine needed!
Date: 13 Apr 92 07:24:22 GMT
Organization: Florida Institute of Technology, Melbourne USA

Dear netters,
I have developed a program that displays different graphs on the screen using
Turbo C v2.0. I would like to be able to print these graphs on a dot matrix
printer.

I would appreciate it very much if anyone could help me with this problem. 
Thanx !

Sincerely,

Adnan Zejnilovic  (rcs76179@zach.fit.edu)
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Need help on how to use fflush(stdin)
Organization: TauMetric Corporation
Date: Thu, 9 Apr 1992 15:28:24 GMT

mitchell@mdd.comm.mot.com (Bill Mitchell) writes:

>I don't know about any pecularities of VMS 'C' in particular, but I
>think the answer to this is that fflush(input_stream) is nonportable

The ANSI/ISO C Standard says that the results of applying fflush() to
a stream whose last operation was input are undefined.  fflush() is
intended to send output data from the stdio buffer to its destination.

Discarding unused input is a different story.  For output, we are just
saying to be sure that anything the program sent to the output stream
should really go there, not be held until the buffer is full.  For
input, it is not clear what it means.

There is no way to specify whether input typed at a terminal (for
example) has or has not been placed in the stdio buffer for the stream.
This depends on how the operating system (if there is one) handles
interactive input (if any is allowed).  The whole topic is one for
operating systems, not the C language, and you have to read the OS
manuals to see what functions are provided to accomplish this.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: jclesius@bbn.com (Jeff Clesius)
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 10 Apr 1992 12:53:15 GMT
NNTP-Posting-Host: bbn.com

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.)"

(; People who make generalizations always get burned! ;)

Showing my age here,
Jeff Clesius (jclesius@bbn.com)
From: david.yap@ehbbs.hou.tx.us (David Yap) 
Newsgroups: comp.lang.c
Subject: FILE FORMAT
Date: 15 Apr 92 19:11:00 GMT
Distribution: world
Organization: Ed Hopper's BBS - Houston, TX - 713-997-7575
Reply-To: david.yap@ehbbs.hou.tx.us (David Yap) 

Can someone tell me where I might find information on
reading/writing Lotus 123 format files, preferably using 'C'?  I
would like to get my hands on source code if possible or else some
good information on how to do it.

I have sent for "File Formats for populor PC software" by Jeff
Walden, which I belive has that information.  But it will take a
while to get here and I don't know if there will be enough source
code info that I can use.  So, if you have had experience doing
this or knwo where I can find the information, I would really
appreciate hearing from you.

Thanks.
                                                             
Xref: sparky comp.lang.c:7447 comp.std.c:1782 comp.arch:4896
From: cgh018@tijc02.uucp (Calvin Hayden x2254)
Subject: GCC on Sparc / ANSI libc.a
Organization: Siemens Industrial Automation, Johnson City TN
Distribution: usa
Date: Mon, 6 Apr 92 19:40:14 GMT

I've posted to gnu.gcc.help, but with no success - only one reply from
Cygnus support, so I'll try my luck here...

We just received the GNU Language tape.
On it we have GCC Version 1.40.  We just finished installing
it on a Sun Sparcstation running SunOS 4.1. We have followed the installation,
and all seemed to go well.  We also did a "make includes" to "fix" some of the
Sun header files and install them in another place.  We have also installed
the binutils ld, and gas.  These are all installed in /usr/isd_tools/gcc/
Now the questions start...

   It appears that gcc uses the standard Sun-supplied libc.a, and Suns
   stdio.h.  Hence, if you have the following you get a compile time warning:
   "...warning: assignment of integer from pointer lacks a cast" 
        ...
        int a;
        a = sprintf(something,"abc");
        ...
   GCC is using the "definition" of sprintf found in Suns stdio.h, and not an
   ansi definition.  Even if it were using an ansi definition, and you did
   not receive a warning, the sprintf routine in Suns libc.a still returns
   a char* and not an int.

   Since gcc is using suns libc.a, and stdio.h (along with other of Suns
   header files), doesn't this imply that, at least on the Suns, that it
   isn't an true ansi compiler.  

   The folks here would like to be able to write, compile and run ANSI C, and
   feel sure that the compiler is using ANSI C header files/definitions, along
   with ANSI C functions, and that the executable isn't buggy due to the 
   compiler/assembler/linker - with the above, they aren't sure of this.
   Have we missed something in our installation, or is this not possible with
   GCC?  It appears to us that GCC supports and understands ANSI C, but that
   if you don't have ANSI header files and ANSI libraries, that you can't 
   truly use it for ANSI C.  Can an alternate set of ANSI libraries for the
   Suns be obtained?  Can an ANSI set of libraries be obtained for Suns?

   Any input/experiences/suggestions/fixes appreciated - hope that this
   was the right place for this.

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
  \  Calvin Hayden                   Uucp: uunet!tijc02!cgh018        \
   \  Siemens Industrial Automation   Inet: cgh018%tijc02@uunet.uu.net \ 
    \                                        cgh018@tijc02.uucp         \
     ~~~~~~~~~~~~ My personal opinions and mine alone! ~~~~~~~~~~~~~~~~~~ 
Newsgroups: comp.lang.c
From: mynzy@world.std.com (Peter H Jurgensen)
Subject: 64 bit pointers?
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 10 Apr 1992 03:36:18 GMT

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.
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 12 Apr 92 12:04:32 GMT
Organization: AND Software BV Rotterdam

In article <mcook.702998942@mrc.dev.cdx.mot.com> mcook@mrc.dev.cdx.mot.com (Michael Cook) writes:
|volpe@bart.crd.ge.com (Christopher R Volpe) writes:
|
|>In article <mcook.702843388@mrc.dev.cdx.mot.com>,
|>mcook@mrc.dev.cdx.mot.com (Michael Cook) 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.
|>|>
|>|>Except arrays.  They're passed by reference.
|
|>Wrong. Arrays aren't passed at all. Pointers are passed. And they're passed
|>by value.
|
|What's the difference between call-by-reference and passing a pointer?

There's no difference between CBR and pointers in C, but there's a subtle
difference in semantics when we're discussing *real* CBR. The pointer is
passed by value in C, but have a look at this C++ code fragmnent:

void f(int *x, int& y) {

void *ip;

ip= (void*)&x;		// see note #1
ip= (void*)&y;		// see note #2

}

Suppose the function f is called as:

int i;

int main(void) {

f(&i, i);

// etc.

}

note #1: ip is assigned the address of the parameter x, (somewhere on the
	 stack probably) this is not the address of the global variable i.

note #2: since y is a reference to the global variable i, and not a pointer
	 to it, ip is assigned the address of the integer variable that y
	 refers to, so ip gets the value &i.


Isn't life wonderful? I'm glad the C and C++ language designers skipped 
the call-by-name mechanism ;-)

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: smclewin@ultrix.ramapo.edu (Scooter McLune)
Subject: Re: C Structures
Organization: University of Delaware
Date: Fri, 17 Apr 1992 04:28:40 GMT

aali@dcs.qmw.ac.uk (ALI) writes:


>I have a structure thus:

>struct this { 	int x;
>				int y;
>			};
>			
>I want to declare an array called temp of type struct this ie:
>struct this temp[10];

>However, I want to declare temp in my main() procedure. This is 
>because the size of the array is figured out from a file which
>contains z number of elements.The file is read by a procedure called in 
>the main() procedure. So my final declaration in my main() procedure is 
>supposed to be:

>struct this temp[z];

>where z is an int.
>	However, it doesn`t work! Can anybody suggest how to do this
>and if I can put my definition of my structure into a header
>file?

>Thanks,

>Al.

You are right about this not working.  The space for a declaration
such as

int temp[10] 

is set aside at compile time, not run time as you need to do it.  So
far as I can see, you have two choices (three if you count giving up :) )

Use the realloc() to dynamically size your array of structures as you need

Declare an array of structures of a size beyond the max you ever think
it will hit, and only use parts of it as you need to.


Solution 1 is nicer, but more difficult to implement
Solution 2 is quick, dirty and wasteful.  enjoy.


SMM


Newsgroups: comp.lang.c,comp.std.c
From: ae56@rz.uni-karlsruhe.de ()
Subject: : Splitting C-modules ?
Originator: ae18@ma70.rz.uni-karlsruhe.de
Keywords: C-Library Compiler Split
Organization: University of Karlsruhe, Germany
Date: Wed, 8 Apr 1992 10:33:11 GMT

The Institute for Applied Mathematics has written a PASCAL-XSC to C translator
which generates for each PASCAL module a corresponding C-module. In order to
generate a library instead of an object file of the current module, we need to
split the C-source into a serie of C-source files for each function. 
Does anybody know whether such a split program exists?

Thank you in advance


Dimitri Shiriaev