HDTenEightyP/NetNews huggingface dataset:
From: bandy@aplcen.apl.jhu.edu (Mike Bandy)
Newsgroups: comp.lang.c
Subject: Re: People's Experience with C Debuggers
Keywords: C debugger experience gdb dbx
Date: 9 Sep 92 02:19:14 GMT
Organization: Johns Hopkins University

simonson@cs.washington.edu (Kevin Simonson) writes:


>     I'm familiar with the C debuggers gdb and dbx.  Are there other C de-
>buggers in common use, and if so, how well do they generally work?  Also,
>how do people rate how gdb and dbx generally work?

>     I know I've had accounts on machines where the local C debugger didn't
>appear to be able to print the values of variables local to the function
>the debugger was currently executing.  I was wondering if other programmers
>had similar problems.

>     Also, does it happen at all, and if so, how often, that people have
>access to C compilers but don't have access to any debugger whatsoever?

>                                     ---Kevin Simonson



I'm spoiled - I grew up with VMS.  All those UNIX debuggers are crap compared
with the VMS symbolic debugger (under any language).  The only debugger that
comes close is the Lattice C debugger on the Commodore Amiga.

	Mike Bandy
	Johns Hopkins University - Applied Physics Lab
	bandy@aplcen.apl.jhu.edu
From: edb1@cbnewsf.cb.att.com (edward.benyukhis)
Newsgroups: comp.lang.c
Subject: Re: How to call procedure with a variable?!
Keywords: C VARIABLE PROCEDURE
Date: 11 Sep 92 14:54:41 GMT
Organization: AT&T

In article <67971@hydra.gatech.EDU> cc100aa@xray.gatech.edu (Ray Spalding) writes:
>In article <1992Sep10.143705.15262@galileo.cc.rochester.edu> eric@prodigal.psych.rochester.edu (Eric Hansen) writes:
>
>#include	<stdio.h>
>
>int
>getnewsearch(int x, int y, int z)
>{
>	return x + y + z;
>}
>
>int (*gotoproc)(int x, int y, int z);
>
>int
>main()
>{
>	int t;
>
>	gotoproc = getnewsearch;
>	t = gotoproc(1,2,3);
_________________________________

This is somewhat erroneous.  The way you invoke a function is:

	t = (*gotoproc)(1,2,3);
	
	

	
	Best regards,
	
	
	Ed Benyukhis
	
Newsgroups: comp.lang.c
From: tim@shovel.Prime.COM (Tim Cantin)
Subject: Re: Turbo C question
Keywords: help atof turboc 2.0
Organization: Prime Computer R&D
Date: Mon, 14 Sep 1992 20:04:25 GMT

Make sure you have this in your source:

#include <math.h>

and the '-f' option on your tcc command line, or in your turboc.cfg file.
It is the default, but it is possible you have it off. The options includes
the floating point emulator in the link.

-- 
#include "stddisclaimer.h"
/* Tim Cantin          {uunet, csnet-relay}!primerd!tim || tim@s35.prime.com
   Prime Computer Inc. 10-21, 500 Old Conn. Path, Framingham, MA 01701 (USA) */
flames > /dev/null 2>&1
Newsgroups: comp.lang.c
From: @gemstone.inel.gov ()
Subject: Conventional Memory Value
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Date: Wed, 9 Sep 92 19:58:45 GMT

I am having a difficult time determining the total conventional memory value
as reported by CHKDSK and MEM.  MEM reports both total conventional memory 
and bytes available to DOS.  I know that the memory available to DOS can be
determined with BIOS interrupt 12h.  But I'm not sure about total conventional
memory.  Is this value calculated, or is there a service available which will
report this value?  Perhaps in the mysterious list of lists?  Can someone 
point me in the right direction?  Thanks for any help. 

-------------------------------------------------------------------------------
 Kevin Hemsley                             |
 Information & Technical Security          | If you think that you have someone
 Idaho National Engineering Laboratory     | eating out of your hand, it's a
 (208) 526-9322                            | good idea to count your fingers!
 kev@inel.gov                              |
-------------------------------------------------------------------------------
========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
Newsgroups: comp.lang.c
From: faivre@cst02.segin.com (Denis Faivre)
Subject: Re: EASY C
Reply-To: faivre%cst02.segin.com@relay.prime.com (Denis Faivre)
Organization: Segin, Groupe Axime
Date: 10 Sep 92 16:52:18 GMT

tony@nexus.yorku.ca (Anthony Wallis) writes:

>BEGIN Is this a joke QUESTION MARK   However COMMA to answer your
>question ELLIPSIS END

You're kidding, aren't you ?   DOUBLE_POINT DASH END

This is definitely no joke. I know someone seriously considering to "adapt" C
(for COBOL programmers, as you guessed it in your second message) by such a
technique as EASY C.
That's why I'm wondering if anybody around did experience EASY C or any analog
pseudo-language.
What are pros and cons of using it ?
-- 
Denis FAIVRE - AXIME                   When anything can go wrong, it w$*& !
Phone : +33 20.60.79.79
E-Mail : faivre@cst02.segin.com
From: mjn@pseudo.uucp (Murray Nesbitt)
Newsgroups: comp.lang.c
Subject: Re: where the program spends its time
Date: 11 Sep 92 08:36:18 GMT
Followup-To: comp.unix.programmer
Organization: Private system in Toronto, ON


ara@zurich.ai.mit.edu (Allan Adler) writes:

>What facilities are there for determining what are the most time consuming
>parts of a C program, which commands are called most often, how long
>a particular routine takes, etc?

On UNIX (tm) systems, you can use the prof(1) command and the
monitor(3) subroutine.

As well, some compilers have a -p option to add profiling code, for
use with prof(1).

(Followups to comp.unix.programmer).

-- 
Murray
Newsgroups: comp.lang.c
From: rujo@ulrik.uio.no (Rune J|rgensen)
Subject: sscanf and portability
Organization: University of Oslo, Norway
Date: Mon, 14 Sep 1992 15:02:31 GMT

If you use types that explisit defines a byte size, e.g.:

typedef short INT16;
typedef long  INT32;

INT16 i16;
INT32 i32;

How do you preserve portability with sscanf? E.g:

  sscanf(s, "%hd %ld", &i16, &i32);

will work in this case, but not when long is implemented as 64 bit. (E.g.
int is 32 bit, then; typedef int INT32;).

Any suggestions?

-Rune Jorgensen
 rujo@ulrik.uio.no
Newsgroups: comp.lang.c
From: ivan@Cadence.COM (Ivan Kissiov)
Subject: Help on linking, please!
Organization: Cadence Design Systems, Inc.
Distribution: usa
Date: Wed, 9 Sep 1992 15:48:28 GMT

	I would like to learn in more details the process on linking
and loading of reallocatable code ( static and dynamic ). Any references are appreciated. I assume it is very simple, because no one writes about it. On the other hand It doesn`t seem trivial to me.

	Thank you very much.


Newsgroups: comp.lang.c
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: Re: Help!!!  Please Read this message!?!?!?!?!...
Organization: National University of Singapore
Date: Wed, 9 Sep 1992 04:25:39 GMT

eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
: eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
: : gmr6139@ultb.isc.rit.edu (G.M. Richard ) writes:
: : : I can't get my compiler to do float-type variables.  I can do 
: : : integers, and I can declare integers, but I can't either 
: : : declare a real number or define a float variable.  This is no 
: : : little typo here - the same programs work when compiled on a 
: : : VAX, but when I compile this program with Turbo C, all I get 
: : : is zeroes for floats.  Take a look:
: : :  
: : : /*  Variable Example */
: : :  
: : : #include <stdio.h>
: : :  
: : : #define apples  4
: : : #define oranges 3.6
: : :  
: : : main()
: : : {
: : :         printf("\nApples = %d\nOranges = %f", apples, oranges);
: : : }
: : :  
: : :  
: : : output:
: : :  
: : : Apples=4
: : : Oranges=0.000000           
: : 
: : Your compiler can't know what orange is... So it assumes that its an
: : int. That's why the wrong result. Alternatives ...
: : 
: : 1) printf("\nApples = %d\nOranges = %f",(int)apples, (float)oranges);
: : 
: : 2) declare 
: : const float oranges = 3.6;
: 
: Sorry, my explanation is obviously misleading. The examples should work
: however.

Sigh.... Before someone writes to me flaming me, I'd better explain. I've
encountered  a similar problem before (can't remember with which
compiler though) and what happened was that the compiler was pushing
ints as arguments.

BTW has anyone ever encountered a compiler (used intensively) that
didn't have a bug of some kind or other?
: 
: : 
: : :  
: : :  
: : : Any help on this problem would be greatly appreciated!!!!
: : :  
: : : 
: : : -- 
: : :   _  _                __                         gmr6139@ultb.isc.rit.edu
: : :  /| /|  __  _/__/_   /__) ' __  /_  __ ,_  __/  gmr6139@george.cs.rit.edu
: : : / |/ |_/-/__/__/____/ \__/_/___/ /_/-/_/__/_/  gmr6139@ritvax.isc.rit.edu
: : : ____________________________________________  gmr6139@ritlav.isc.rit.edu
: : 
: : jin meng
: 
: jin meng


jin meng
Newsgroups: comp.lang.c
From: jutta@opal.cs.tu-berlin.de (Jutta Degener)
Subject: Re: problem with "external pointer"
Organization: Techn. University of Berlin, Germany
Date: Mon, 7 Sep 1992 21:52:17 GMT

dave@cs.arizona.edu (Dave Schaumann) writes:
>In article <xu.715880256@prim.rose.utoronto.ca>, xu@prim (Jiefeng Xu) writes:
>> Can I define a pointer and use it as an external variable?
>> If I use the following
>>
>> extern int *ps;
>>
>> my compiler (gcc) will ignore it and consider the ps as undefined.
>
> What you have to understand is that "extern int *ps;" is a /definition/ of
> "ps".  You still need to have a declaration of "ps" somewhere in your source
> code.  If you don't, the linker will complain (and rightly so).

The names are the other way around.  These are definitions:

		int * ps;
		char progname[] = "myprog";
		int main() {  return 0; }

Defining means "to end"; to make a border between this and other
things; thus, to determine what it is.  Imagine staking claims:
"I want this to be a pointer to int, a character array goes here,
these bytes are going to be a struct timeval."


On the other hand, these are declarations:

		extern struct bottle vodka[10];
		extern int * ps;
		int main(); 		/* You don't need "extern" here */

You declare goods in a customs declaration when you travel between
countries.  They don't suddenly pop into existence when you talk
about them; first you have to buy the ten bottles of vodka, then
you can tell somebody about them.


What has this to do with extern?  The word "extern" is used for two
slightly different things:

- as a keyword, meaning (a) "this is a declaration, not a definition," 
  and (b) "the thing I refer to has global/external scope"

- and when talking about identifiers, as a scope, meaning "global,
  accessible to all translation units".

All functions or objects you declare to the compiler with the `extern'
keyword do have extern scope; but not everything with extern scope
has to involve the `extern' keyword.

When writing
		int * ps;

outside of a function, you have defined (and implicitely also
declared) a variable with "external", i.e. global, scope.

You only need to declare it

		extern int * ps;

if it is not in scope yet, if the compiler does not know about it --
because it is defined in a different translation unit, or because it
is going to be defined later in the same unit.


--Jutta
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Warning
Date: 9 Sep 92 17:51:05 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <14427@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
|> Also the original programmers made a point of never using "extern" if they
|> could possibly help it, so there were several things like
|> 	/* File: lexer.c */
|> 	int yyerrs;		/* note no initialisation */
|> 
|> 	/* File: parser.c */
|> 	int yyerrs;		/* note no initialisation */
|> 
|> My understanding is that these are tentative definitions, and that's ok.

The concept of "tentative definition" applies only within a translation
unit. That is, this is ok:
	/* File: foo.c */
	int foo;
	/* more stuff */
	int foo;

as is this:
	/* File: foo.c */
	int foo;
	/* more stuff */
	int foo=1;

|> However, this compiler appears to get it wrong; sticking extern in front
|> of either one made the linker error message go away.

The compiler is fine. Each tentative definition becomes a definition at
the end of EACH TRANSLATION UNIT. Thus, you have a multiple definition 
between those two translation units. This is not allowed. (Though most
unix linkers I've seen extend the "tentative definition" concept to 
allow this. )

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.lang.c
From: mjn@pseudo.uucp (Murray Nesbitt)
Subject: Re: Help!!! Please Read this message!?!?!?!?!...
Organization: Private system in Toronto, ON
Date: Tue, 15 Sep 1992 05:55:53 GMT
	<1992Sep10.040600.27065@blaze.cs.jhu.edu>
	<MJN.92Sep11001608@pseudo.uucp>
	<1992Sep11.131151.891@klaava.Helsinki.FI>


wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:

>mjn@pseudo.uucp (Murray Nesbitt) writes:
>>    printf( "%f...%s?\n", (float)f, "Huh?" );
>>
>>It's another matter whether you'd *want* to pass a float to printf(),
>>but it is possible.

>No, not possible.  You can cast a value to float, but before it is
>passed as a parameter, it is automatically and unavoidably converted
>into a double.

You're right, of course - I must have had a brain fart when I posted
that.

>[...] ``default promotions'', in which, basically (I may have a few
>details wrong, especially about signed/unsigned promotions) integers
>smaller than int become int and float becomes double.

To be specific, the integral promotions are: ``char'', ``short int''
and ``int'' bit-field types (and signed or unsigned variants of
these), and enumeration types, will be promoted to ``int'' if they can
be represented as such. Otherwise they are promoted to ``unsigned
int''.

-- 
Murray
Xref: sparky comp.lang.c:13350 comp.sources.d:1249 comp.unix.wizards:3849 alt.sources:2019 misc.misc:3274
From: tpa10@ccc.amdahl.com (Thomas P. Anderson)
Newsgroups: comp.lang.c
Subject: Re: Help!!!  Please Read this message!?!?!?!?!...
Date: 8 Sep 92 14:16:27 GMT
Reply-To: tpa10@JUTS.ccc.amdahl.com (Thomas P. Anderson)
Organization: Amdahl Corporation, Sunnyvale CA

In article <1992Sep8.002536.18118@ultb.isc.rit.edu> gmr6139@ultb.isc.rit.edu (G.M. Richard ) writes:
>I can't get my compiler to do float-type variables.  I can do 
>... (some deleted) ...  this program with Turbo C, all I get
>is zeroes for floats.  Take a look:
> 
>/*  Variable Example */
>#include <stdio.h>
>#define apples  4
>#define oranges 3.6
>main()
>{
>        printf("\nApples = %d\nOranges = %f", apples, oranges);
>}
>output:
>Apples=4
>Oranges=0.000000           
> ... (more deleted)
I'm suprised you didn't get any warnings from TC.  Try "#include"ing
float.h.  Also, did you install the floating point libraries, and/or
does your link command include them?  Just for grins add lines to
declare a float variable and try and do some math on it, I bet the
linker chokes on you.

Tom A.
From: s913578@yallara.cs.rmit.OZ.AU (Fantom)
Newsgroups: comp.lang.c
Subject: Sets in C
Date: 8 Sep 92 03:10:52 GMT

I've been looking at implementing sets in C,
the method needs to be able to handle sets of more than 32 elements
so using bit fields won't work

Using arrays, etc would be fine, except that I want to be able to 
put soemthing into the set for the duration of a function call only

eg

void foo()
{
        settype S;
	bar(set(elt1 elt2 elt3 S));
}

the set S should be unchanged by the call to bar

The application i needed it in had sets of 50 elts, so i used
two bitfields and passed 2 parameters to bar.  Each element of the set
was assigned a position in either the first or second bitfield

Any other ideas (my method is extremely bulky)

thanks 
	Fantom
Newsgroups: comp.lang.c
From: pjh@mccc.edu (Pete Holsberg)
Subject: Re: Why should POINTERS be so damn hard to understand ?
Organization: The College On The Other Side Of Route One
Date: Sun, 6 Sep 1992 17:54:32 GMT

In article <1992Sep5.054703.24868@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:
=In <1992Sep03.154038.27377@syscon.rn.com>
=   carl@syscon.rn.com (Carl Kreider) writes:
=
=>Certainly true, but I thought that "*p++ = *s++" derives directly from
=>"mov (r0)+,(r1)+" for example.  In that sense C is high level assembler.
=
=Isn't it in every sense? I thought that C was *supposed* to be a
=portable macro assembler. [ 1/2 ;-) ]

From BSTJ, July/Aug 1978, "The C Programming Language", by D.M.Ritchie,
S.C.Johnson, M.E.Lesk, and B.W.Kernighan, page 1991:

"C is not a 'very high-level' language...The language is sufficiently
expressive and efficient to have completely displaced assembly language
programming on UNIX."
From: michi@ptcburp.ptcbu.oz.au (Michael Henning)
Newsgroups: comp.lang.c
Subject: Re: Help!!! Please Read this message!?!?!?!?!...
Date: 9 Sep 92 00:22:49 GMT
Organization: Pyramid Technology Corporation

gmr6139@ultb.isc.rit.edu (G.M. Richard ) writes:

>I can't get my compiler to do float-type variables.  I can do 
>integers, and I can declare integers, but I can't either 
>declare a real number or define a float variable.  This is no 
>little typo here - the same programs work when compiled on a 
>VAX, but when I compile this program with Turbo C, all I get 
>is zeroes for floats.  Take a look:
> 
>/*  Variable Example */
> 
>#include <stdio.h>
> 
>#define apples  4
>#define oranges 3.6
> 
>main()
>{
>        printf("\nApples = %d\nOranges = %f", apples, oranges);
>}
> 

Your compiler is probably not linking against the floating point version
of printf, because it does not see any float or double declarations.
Complain to the vendor, your program is valid and should produce the
correct output (as indeed it does with dozens of other compilers).

							Michi.
-- 
      -m------- Michael Henning                 +61 75 950255
    ---mmm----- Pyramid Technology              +61 75 722475 FAX
  -----mmmmm--- Research Park, Bond University  michi@ptcburp.ptcbu.oz.au
-------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA   uunet!munnari!ptcburp.oz!michi
Newsgroups: comp.lang.c
From: pjh@mccc.edu (Pete Holsberg)
Subject: Re: Why should POINTERS be so damn hard to understand ?
Organization: The College On The Other Side Of Route One
Date: Mon, 7 Sep 1992 20:50:00 GMT

In article <14367@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
=How often do I have to say it?  "move (r0)+,(r1)+" is a PDP-11 instruction.
=The PDP-11 was _NOT_ the first machine C ran on, nor the machine C was
=designed for.

Ritchie, Johnson, Lesk and Kernighan say otherwise in BSTJ, July/August,
1978: "C was originally written for the PDP-11 under UNIX..."
From: shrchin@csug.cs.reading.ac.uk (Jonathan H. N. Chin)
Newsgroups: comp.lang.c
Subject: Re: 1992 International Obfuscated C Code Contest winners
Date: 14 Sep 92 21:05:40 GMT
Organization: University of Reading

scs@adam.mit.edu (Steve Summit) writes:
>In article <shrchin.716270955@reading>, shrchin@csug.cs.reading.ac.uk (Jonathan H. N. Chin) writes:
>> barmar@think.com (Barry Margolin) says:
>>> In article <268@talgras.UUCP> david@talgras.UUCP (David Hoopes) writes:
>>>> In article <1992Sep10.135002.25527@wraxall.inmos.co.uk> nathan@elberton (Nathan Sidwell) writes:
>>>>> As chongo stated, my entry can't be posted from the USA.
>>>> Why couldn't your program be posted from the U.S?
>>> I haven't examined it, but I'll bet... that posting it from the US...
>>> would be a violation of export control laws regarding munitions.
>> So what happens now that it has (I assume) entered the US via news?
> [...long serious answer elided...]

oops. forgot the smileys.

Cascade!! Cascade!!


-- 
Jonathan H N Chin (9 kyu) \ Dept. of Cybernetics, \ "Respondeo, etsi mutabor"
shrchin@uk.ac.rdg.susssys1 \ University of Reading \
bq305@cleveland.freenet.edu \ Box 225, Whiteknights \ < Rosenstock-Huessy >
jockstrap,mandy@CyberSpaceII \ Reading, RG6 2AY, U K \
From: steve@taumet.com (Steve Clamage)
Subject: Re: free() problem ...
Organization: TauMetric Corporation
Date: Wed, 9 Sep 1992 15:33:20 GMT

wangyu@ccwf.cc.utexas.edu (Yu Wang) writes:

>I got a question on free().  It looks to me that free() doesn't
>actually make freed memory spaces available to other programs.

free() is not required to do much of anything.  It needn't make
the memory available to the *same* program, but most programmers
would consider such an implementation deficient.  (On a large system
with lots of real memory and a large virtual memory space, it might
make sense never to reclaim storage.  Programs might run much faster
without the overhead of reclaiming memory.)

Whether free() returns memory to the operating system for use by
other processes is not addressed by any C langauge standard.  On
many multi-user operating systems, it doesn't make any sense to
return free'd memory.  Doing so would slow down the current
program and potentially all others on the system when the program
again requested the free'd space.  Some OS's ignore attempts to
return the space anyway, for that reason.

Recall that malloc/free are general-purpose allocators, and no one
strategy can give optimum performance for all possible programs.  The
case of allocating and freeing a huge block exactly once is probably
very rare, and it wouldn't make sense to optimize that rare case.

If this is an issue for your program, you can write your own special-
purpose allocator which takes advantage of whatever OS features are
appropriate to get and return a single large block of memory.  Many
systems have the OS functions brk(), sbrk(), and/or lsbrk().  Their
use may conflict with the standard malloc/free, however, so use
them with care.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: EASY C
Organization: Texas Instruments Inc
Date: Mon, 14 Sep 1992 16:12:25 GMT

In <faivre.716417831@cst02> faivre@cst02.segin.com (Denis Faivre) writes:

>mjn@pseudo.uucp (Murray Nesbitt) writes:

>>If you want Pascal, you know where to find it.

>The goal isn't to change to another language, but to make C easier to learn,
>easier to read and easier to debug for programmers used to deal with COBOL.

Except that it doesn't do that, since once they get done abusing the
preprocessor, the result is no longer C.  They are using some other
language entirely.  The person using 'Easy C' doesn't know how to read
or write C.  And as for the person who inherits their code to
maintain, they should be given a license to hunt down the original
author and do something massive and permanent to them.  Something slow
and lingering comes to mind.

-- 
"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.
Newsgroups: comp.lang.c