HDTenEightyP/NetNews huggingface dataset:
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: strcpy implementation question
Date: 27 Aug 92 09:11:14 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <9224017.23144@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >This is wrong.  It isn' the source or the destination that cares, it is
> >strcpy() that cares.  strcpy() MUST NOT READ any uninitialised memory
> >locations.
> 
> I'm sorry, but this is wrong.
> The code to implement strcpy() does NOT have to be ansi-conformant - hell,
> it doesn't even have to be written in C!

The *implementation* of strcpy() can do anything it XXXing well pleases.
The point I am making is that in the "model machine" it is not legal to
refer to uninitialised locations.  That is, the behaviour of strcpy()
-- however it is implemented -- must not be distinguishable from the
behaviour of a a "model" implementation which does not touch uninitialised
locations.  It must not be detectable that strcpy() has read any uninitiliased
locations.  Let me see if I can make the argument a little clearer.

Suppose I have a destination array, allocated by the compiler, and of known
size.  Suppose I have already initialised all the elements of that array,
somehow.

	static char a[48];

This is by definition initialised to 0, so every element of this array is in
a defined state.  Now suppose I do

	strcpy(a, "foobarglezorch");

This involves moving a defined sequence of characters to an area which is
quite big enough for it and which does not overlap the source.  The effect
of strcpy() _isn't_ defined when source and destination overlap, but when
they don't overlap, a[] should still be completely defined afterwards.  One
way of understanding this is that the "model" strcpy() should never read
undefined characters, or you'd get undefined behaviour.

Put it this way, the destination ALWAYS cares.
-- 
You can lie with statistics ... but not to a statistician.
From: arensb@kong.gsfc.nasa.gov (Andrew Arensburger - RMS)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 27 Aug 92 00:53:28 GMT
Organization: Goddard Space Flight Center

barmar@think.com (Barry Margolin) writes:
>In article <chuckb.714781695@milton> chuckb@milton.u.washington.edu (Chuck Bass) writes:
>>I would bet that assembly language programmers have no problem
>>picking up C's notion of pointers.
>I disagree.  Assembly programmers are used to pointers being addresses, and
>arithmetic on pointers being address arithmetic.  They're probably the ones
>who get most confused by C's automatic scaling during ptr+integer
>calculations, and don't understand why p+=sizeof(*p) doesn't do what they
>expect.

	Actually, for me, at least, a lot of C finally started making
sense after I had done some assembly programming: a lot of questions
can be answered by "because it makes the compiler easier to write."
(A colleague of mine once remarked that "cc is the most powerful macro
assembler you'll ever use.")  I learned a lot about both C and
assembly by looking at the assembly code generated by a C compiler.
	As for automatic scaling, that's a corollary of having pointers
and arrays be as similar as possible, which in turn is a corollary of
wanting the compiler to be as simple as possible.

\begin{rant}
	This, by the way, is one reason I hate ANSI's "void": it seems
to have any size at all, depending on context. But you can't declare a
variable as being of type "void". It tries to fulfill the same role as
K&R's "char *", but doesn't mesh nicely with C As We Know And Love(d) It.
	Now, if the ANSI committee had defined a type 'byte' to be of
the smallest size that can be represented on the host architecture,
it would have made sense.
\end{rant}
	Followups to comp.lang.c.advocacy .

--
----- Tasteless .sig coming up --------------------------------------------
Andrew Arensburger            | But Andrew is no kind and gentle breeze:
arensb@kong.gsfc.nasa.gov     | Andrew is a HURRICANE! He demands
...!uunet!dftsrv!kong!arensb  | SACRIFICE!
Newsgroups: comp.lang.c
From: langlois@doe.carleton.ca (Francis Langlois)
Subject: Re: Combine c and c++?
Organization: Dept. of Electronics, Carleton University
Date: Wed, 26 Aug 1992 14:42:51 GMT

In <igrdb.714837537@hrz.tu-chemnitz.de> igrdb@informatik.tu-chemnitz.de (Ingo Gringer) writes:

>Hi everywhere, 

>Please be indulgent if that's just another nonsense question!
> 
> I try to connect two applications which are programmed in c++
> and otherwise in c. Now I want to combine these programs, but
> there is an hump: they need their own libraries and the c-
> application is not compiled through the c++. It fails with the 
> error, that a function used in the special c-library is not
> declared. Thats correct but doesn't irritate the c-compiler.
> I dont know where he obtains his informations. One lib contains 
> finally the needed function. 

> Is it possible to link the object files produced by c++ or c 
> together? Trying this generates permamently an error that my
> function I wrote in the c-programm are not defined. But 
> I told the c++ - part everything with my headerfiles. 

>What is wrong? Why doesn't it works?

when you include the c protoype in C++ did you use the

  extern "C" prefix.

>Any hints would be very much appreciated.
>  
  I believe this is you only problem.  You see C++ uses name mangling
and C does not.  By using the extern "C" prefix you tell the compile
this function or data type or what ever is to be compiled so it looks
like C not C++.

  >Please responds by email.  >Ingo

eg.

 extern "C" int* foo(void); // is a prototype to C function which may
			    // or may not have been compiled with C++

T.T.F.N....Francis
_____________________________________________________________
| Dept. of Electronics     |                                 |
| Carleton University      |  email langlois@doe.carleton.ca |
| Ottawa Ontario	   |  Phone (613)-788-2600 x1825     |
| K1S 5B6	           |  Fax   (613)-788-5708           |
|__________________________|_________________________________|


--
T.T.F.N....Francis
_____________________________________________________________
| Dept. of Electronics     |                                 |
| Carleton University      |  email langlois@doe.carleton.ca |
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: printf question
Organization: TauMetric Corporation
Date: Wed, 2 Sep 1992 15:26:27 GMT

jcoxhead@acorn.co.uk (Jonathan Coxhead) writes:


>   In article "Re: printf question" karl@ima.isc.com (Karl Heuer) writes
>parenthetically

>> The C preprocessor has no way to evaluate-and-stringise a constant
>> expression.

>but it does!

>      #define STR_(s) #s
>      #define STR(s)  STR_ (s)

>      #define WIDTH 8

>      printf ("%" STR (WIDTH) "x", n);

The key word in Karl's statement was "evaluate".  Your example only
works with simple constants.  Try it with
	#define MAX 80
	#define COLS 4
	#define WIDTH MAX/COLS-2
after preprocessing and string concatenation the printf looks like this:
    printf ("%80/4-2x", n);
which doesn't do anything useful.  Macro replacement does not involve
expression evaluation, only text substitution.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Date: Wed, 26 Aug 92 07:59:00 +0200
From: Gilles_Kohl@spam.fido.de (Gilles Kohl)
Subject: Simple C question
Newsgroups: comp.lang.c
X-Comment-To: (Shuang Ji)
Organization: To take arms against a C of troubles ... 

 >|>  > ccom: Error: test.c, line 6: no automatic aggregate initialization
 >|>  >        char s[] = "Hello world!" ;
 >|>
 >|>  > Can anybody please explain why automatic initialization is not accepted

 > Variables declared as "char s[]" are not considered to be left values.
 > And in fact, the value of the string "Hello world" is the address of
 > this staticly stored string. So this initialization is illegal.
Shuang,

initialization is not assignment. ANSI C allows initialization of automatic 
arrays and structures - K&R (1st ed.) did not. I think I stated this in my 
message to the original poster, why did you omit the relevant part ?

Regards,
Gilles.

---
Newsgroups: comp.lang.c
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: call graph tool
Keywords: call graph tool
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Thu, 03 Sep 1992 21:46:42 GMT

In article <1992Sep2.135915.26135@riacs.edu> okuyama@pioneer.arc.nasa.gov (Darin Okuyama YR) writes:
>Does anyone know of a widely available tool that will produce a call graph of
>a C program by reading its source.

Look for something named `calls'.  If you can't find it in the usual archive
sites, I believe ksb@cc.purdue.edu is the current caretaker.
Newsgroups: comp.lang.c
From: eric@orfeo.radig.de (Eric Tuerlings)
Subject: pointer to araay of structs
Summary: how to use: void (struct aaa (bbb *)[])   ?
Keywords: pointers
Organization: Peter Radig EDV-Beratung, Frankfurt am Main, Germany
Date: Mon, 24 Aug 1992 21:52:46 GMT


Hello world,

I've encountered a small problem with our (ANSI) Microtec C cross compiler.
See this small piece of code below:

struct aaa {
    char y;
    char z;
}

void func (struct aaa (*bbb)[])
{
    char z;

    z = bbb[3]->ccc;
}

in which bbb is a pointer to an array of aaa structures. The compiler
complains about an unknown size. If I give the array a dimension, the
compiler doesn't complain, but that is not what I want. I want func to
handle different array sizes. Ok I know that I simply can leave out the
square brackets, and use some casting in func, but that is not wat I want
too. I like to tell the compiler that func must accept pointers to _arrays_
of aaa structures.

I've had contact with the Microtec hot line in Gemany. (Ottobrun/Munich)
Still awaiting their answer, I like to hear from people on the net what they
think about this C problem. It is possible that my C knowledge is the problem.
(At least the lack of it -)
-- 
Eric Tuerlings,Stresemannallee 63,6000 Frankfurt am main(argc,arcv) 70,Germany.
Tel: +49 69 6316870, E-Mail: eric@radig.de ---- Leben wie ein Gott in Frankfurt
Newsgroups: comp.lang.c
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Organization: Los Alamos National Laboratory
Date: Fri, 4 Sep 1992 17:56:37 GMT

In article <7228@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
|> In article <1992Sep3.162038.28706@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|>  > [...]
|>  > CDC's Scope was *much* easier to use.  Being a `vintage' system, it had
|>  > about the same capabilities as UNIX.
|> Eh?  What about the approximately flat file system, the inconsistency
|> between programs with respect to their argument handling?  [...]

[... Long list of inconsistencies elided ...]

See?  About the same level of capabilities.  Just as I said.
Inconsistencies are rampant in *both* systems.  Scope was easier
to learn and use.  Both are now *obsolete*.  Only one is still 
being promoted.

-- 
J. Giles
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Should C compiler flag error for this?
Date: 29 Aug 92 14:33:46 GMT
Organization: AND Software BV Rotterdam

In article <1992Aug27.235703.5614@informix.com> subodn@informix.com (Subodh Nijsure ( Su-bo-d Ni-j-su-ray )) writes:
|For the following program should a C compiler flag an error or a warning.
|
|#include <stdio.h>
|extern int i;
|static int i=30;
|main()
|{
|	printf("Value of i is %d\n",i);
|}

Yes, because the behavior is undefined. According to the standard:

ANSI-C 3.1.2.2 Linkage of identifiers

If the declaration of a file scope identifier for an object or a function
contains the storage-class specifier _static_, the identifier has internal
linkage.

If the declaration of an identifier for an object or a function contains
the storage-class specifier _extern_, the identifier has the same 
linkage as any visible declaration of the identifier with file scope.
If there is no declaration with file scope, the identifier has external
linkage.

[ ... ]

If, within a translation unit, the same identifier appears with both
external and internal linkage, the behavior is undefined.

[ end quote ]

Things are a bit tricky here. The second paragraph refers to your
first declaration `extern int i'. There is _no visible declaration yet_
in the translation unit, so the identifier `i' has external linkage.

The first paragraph refers to your second declaration (and definition)
`static int i= 30.' hereby redeclaring the identifier `i' to have
internal linkage.

This third paragraph refers to this situation, so the behavior is
undefined. If you would have written:

static int i= 30;
extern int i;

all would have been fine, because identifier `i' is already visible,
visible by the time the second declaration is read, so the use of the
keyword `extern' wouldn't cause any change in linkage.

But you'd better watch out with this `undefined behavior' stuff. I've
heard about TV sets, exploding when you've got a penguin on top of it! ;-)
No, seriously, my experience is that most compilers just warn you for
it and change the linkage according to what the compiler writer 
thought was sensible. Check your manuals to see what your compiler does.

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: u8800914@cs.uow.edu.au (Mohammad Salim Olime)
Subject: HELP:TURBO C. Waking a TSR by calling an Interrupt
Summary: invoking TSR by an Interrupt and pass argument.
Keywords: TSR
Organization: Dept of Computer Science, Wollongong University, Australia
Date: Fri, 4 Sep 1992 06:05:23 GMT

Normally TSRs are invoked by HOTKEYS But I need to do that inside a Turbo C 
program. I would like to invoke the TSR when ever I wanted using interrupt
rather than HOTKEYS and  be able to pass argument either by refernce or by
value in other word I would like to pass a list which TSR can work on
and then get the result back in some form when I wanted. 
I would be most greatful if anyone can shade some light on the matter.
With regards in advance.
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Organization: Texas Instruments Inc
Date: Tue, 1 Sep 1992 18:55:46 GMT

In <1992Aug27.003746.8092@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

>In article <1992Aug26.210446.13402@mksol.dseg.ti.com>, mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>|> In <1992Aug25.161037.29594@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>|> 
>|> >In article <1992Aug13.175711.27749@mksol.dseg.ti.com>, mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>|> >|> [...]
>|> >|> Find another job, Jim.  One that lets you use something nice and
>|> >|> simple like MS-DOS.
>|> 
>|> >This is an example of UNIX-speak.  This comment is frequently encountered,
>|> 
>|> No, Jim.  This is an example of how to speak to someone who is without
>|> a clue and whining about that state.

>Oh, so your intent was not to commit a logical fallacy (an appeal to an
>irrelevant alternative), but to make an ad-hominem attack.  The latter
>hurts your credibility more than the former.

No, Jim, my intent was to suggest that if you found UNIX so bad
because it was complex that you should seek something MUCH simpler.  I
think you better leave interpreting my intent to me; you're lousy at
it.

As for credibility, I think you lost yours after about the third round
of your periodic crying about how they're making you use UNIX.  One
more time; if you don't like UNIX and C, get another job where you
don't have to.


-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Xref: sparky comp.lang.c:13063 comp.lang.c++:13147
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Tool for measuring size (no. of statements) of C/C++ programs
Keywords: metrics, size, complexity, comparing versions
Date: 1 Sep 92 14:12:55 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Followup-To: comp.lang.c
Organization: University of Arizona

In article <1992Aug31.230930.16232@gtephx.UUCP>, zeranguek@gtephx (Karl Zerangue) writes:
>We are in the market for a tool which produces the size (in numbers of
>statements) of C/C++ programs.

Well, a simple solution to this would be to go get Jim Roskind's C/C++
grammars, and for every production of the form

	statement : whatever

append "{ Statement_Count++ ; }".  Then add this code:

	/* Presumably, no human would write a program with >65536
	 * statements, but there's also code out there not (directly)
	 * written by humans.
	 */
	unsigned long Statement_Count = 0 ;

	main() {

	  yyparse() ; printf( "%d statements.\n", Statement_Count ) ;

	}

However, you may wish to consider the wisdom of a metric that completely
ignores changes to declarations, comments, and other non-statement areas
of the code.  On the other hand, I guess the above would be better than
nothing.

>Ideally, we would like such a tool to
>tell us how a new version of a module changed as compared to some previous 
>version, i.e., where did differences in the numbers of statements occur.
>This would be somewhat like the UNIX 'diff' command, except that this tool
>must be sensitive to what a *statement* is.

For something like this, you'll probably want to run a diff-like algorithm
on token sequences.  Check the literature on "minimum edit distance"
algorithms for more information.

-- 
What signature?
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: C vs. FORTRAN
Organization: TauMetric Corporation
Date: Fri, 4 Sep 1992 15:28:37 GMT

svec5@menudo.uh.edu (T.C. Zhao) writes:

[ the question concerned a program with a million sin and cos calculations
  in C and in Fortran ]

>Yet another possibility (although it won't explain the huge difference):
>Fortran compiler knows the sin and cos functions and hence there is
>a possibility to do inlining while C compiler is not aware of these
>functions and there is no possibility of doing so without violeting
>the standard.

Not so.  When the <math.h> header is included (which is was in the
example), 'sin' and 'cos' become reserved identifiers, and the C compiler
is free to make use of special knowledge about them.  For example, it
might generate a single math processor instruction to calculate sin or
cos.  This is allowed by the C Standard for all standard library
functions.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: amn@unix.brighton.ac.uk (Anthony Naggs)
Newsgroups: comp.lang.c
Subject: Re: printf question
Date: 28 Aug 92 23:55:20 GMT
Reply-To: amn@vms.brighton.ac.uk
Organization: University of Brighton, England

Edward H. Truex, <eht@coos.dartmouth.edu> wants a simpler way of doing:
> #define ADDR_BITS 16
>
> ... blah blah ...
>
> main( int argc, char *argv[] ){
>
> ... blah blah ...
>
> sprintf( format_string, "%%0%dx\n", ADDR_BITS/4 );
> printf( format_string, address );
>
> ... blah blah ...
>

> exit(0);
> }

A couple of answers come to mind, answer 1 removes the sprintf:
1> #define ADDR_BITS 16
1>
1> ... blah blah ...
1>
1> main( int argc, char *argv[] ){
1>
1> ... blah blah ...
1>
1> /* the '*' takes an int from the parameter list for the field width */
1> printf( "%*x\n", ADDR_BITS/4, address );
1>
1> ... blah blah ...
1>
1> exit(0);
1> }

Answer 2, as requested, incorporates the defined value in the format string:
2> #define DISP_DIGITS "4"                  /* Displayed digits as a string */
2>
2> ... blah blah ...
2>
2> main( int argc, char *argv[] ){
2>
2> ... blah blah ...
2>
2> /* Uses ANSI C concatenation of string literals */
2> printf( "%" DISP_DIGITS "x\n", address );
2>
2> ... blah blah ...
2>
2> exit(0);
2> }

Regards, Anthony Naggs

Software/Electronics Engineer                   P O Box 1080, Peacehaven
                                                East Sussex  BN10 8PZ
Phone: +44 273 589701                           Great Britain
Email, (c/o Univ of Brighton): amn@vms.brighton.ac.uk
Newsgroups: comp.lang.c
From: blume@dynastar.Princeton.EDU (Matthias Blume)
Subject: Re: Novice Questions
Reply-To: blume@dynastar.Princeton.EDU (Matthias Blume)
Organization: Dept. of Computer Science, Princeton University
Date: Mon, 31 Aug 1992 21:02:44 GMT

In article <1992Aug31.093741.132@physc1.byu.edu>,
robertson@physc1.byu.edu writes:
|> In article <1992Aug31.070123.23997@klaava.Helsinki.FI>,
wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
|> > Arrays and pointers are nowhere near equivalent.  Superficially they
|> > might look so, but that is only because arrays usually automatically
|> > become pointers in C (but sometimes don't).  For more information,
|> > please read the FAQ of this group, section 2 especially.
|> > 
|> > Btw, the person who said that array names are constant pointers might
|> > want to look at questions 2.6.
|> 

Sorry for bothering you -- I was the person who said this.
Of course, I knew about the differences. I merely tried to
suggest a simple ``rule of thumb'', how C novices might remember
the most appearent difference between pointers and arrays:
An array is not a lvalue! But most of the time, expressions of
type ``array of T'' are converted to type ``pointer to T'', so
it appears as if array-names were pointers.
Here is the appropriate quote from K&R2 (page 200,
App. A, par. A7.1 "pointer generation"):

	"If the type of an expression is 'array of T,' for some
	type T, then the value of the expression is a pointer to
	the first object in the array, and the type of the
	expression is altered to 'pointer to T.'  This conversion
	does not take place if the expression is the operand to
	the unary & operator, or of ++, --, sizeof, or as the
	left operand of an assignment operator or the . operator.
	Similarly, an expression of type 'function returning T,'
	except when used as the expression operand of the & operator,
	is converted to `pointer to function returning T.'"


-Matthias
From: kimcm@login.dkuug.dk (Kim Chr. Madsen)
Newsgroups: comp.lang.c
Subject: Re: printf question
Date: 27 Aug 92 19:26:21 GMT

eht@coos.dartmouth.edu (Edward H. Truex) writes:


>I am trying to format a hexadecimal number whose width 
>is always a constant - like 

>	printf("%04x\n", address );

try to use the variable width specification method:

	printf("%0*x\n",4, adress);

an asteriks in the width specification is taken as a variable that
must be taken from the arguments and be evaluated at runtime...


					Kim Chr. Madsen
From: harrison@lclark.edu (Mark Harrison)
Newsgroups: comp.lang.c
Subject: Re: How to link in .BGI files? (TC++ v1.0)
Date: 2 Sep 92 17:55:11 GMT
Article-I.D.: lclark.1992Sep2.175511.14692
Organization: Lewis & Clark College, Portland OR

In article <1992Sep2.161847.19590@cs.umb.edu> cteague@ra.cs.umb.edu (Charles F. Teague II) writes:
>
>  OK, I give up.  I've written a small program that uses TC's graphics
>functions.  It compiles and runs fine -- so long as the EGVVGA.BGI file
>is in the current directory.  I don't want to copy this file everywhere on
>my hard disk, so I tried to link it in.  A file called BGIOBJ.EXE looked
>promising, so I ran it w/o args for a help message.  I got one, sort of.
>It's no help to me, though.  I've ransacked all four manuals I got with
>TC++ v1.0 (Getting Started,User's Guide,Prog. Guide, + Lib. Ref.), and all
>I've found said that I have to have the bgi files in the current directory.
>
I just checked my BGIOBJ from TC 3.0.  I have never used it, but
appearantly, it converts *.bgi into *.obj format.  Then you would link that
with your program.  Like I said though, I've never done it, so I can't say
if there something I've missed.


-- 
=============================================================================
Mark Harrison           |  "We are the Priests, of the Temples of Syrinx
harrison@sun.lclark.edu |   Our great computers fill the hallowed halls."
              -- Me     |                                    -- Rush