HDTenEightyP/NetNews huggingface dataset:
From: cae@davidge.com (Caleb Epstein)
Subject: Re: line number in C program
Summary: use __LINE__
Organization: Davidge Data Systems Corp., NYC, NY
Date: Tue, 6 Oct 92 16:53:38 GMT

hm@cs.brown.edu (Harry Mamaysky) writes:
>
>Is there a way for me to find out what line number is currently being
>executed in a c program from within that program?
>Will this method also work in C++?
>

    Use the __LINE__ macro.  This is expanded by the
preprocessor (i.e. at compile time) and can be useful for
constructs like this:

|   if (error_condition)
|       fprintf(errfile, 
|               "Fatal error in file %s, line %d",
|               __FILE__, __LINE__);

There is also a __FILE__ macro (see code above) which
expands to the name of the file being compiled.

    These macros should exist in any ANSI-conforming
compiler and may be present in many non-conforming
compilers, too.  You'll have to check your compiler
yourself.

>Harry.
>hm@cs.brown.edu

-- 
[ Caleb Epstein ][ Davidge Data Systems Corp, New York, NY ][ cae@davidge.com ]
[      Someone's definitely jumping into the tub ... with your brother!       ]
From: snowdond@cs.man.ac.uk (Dave Snowdon)
Newsgroups: comp.lang.c
Subject: Request: co-routine library
Date: 2 Oct 92 14:42:18 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

Does anyone have (or know where to get) a PD implementation of co-routines
written in C? Ideally it would be fairly portable, but if it only runs on
SUNs thats OK. I need to be able to dynamically create and destroy
co-routines and to be able to transfer control from co-rotine to another.
			thanks
				Dave

-- 
Dave Snowdon
Department of Computer Science   Tel:    (UK) 061 275 5717
Manchester University            E-mail: snowdond@cs.man.ac.uk
M13 9PL U.K.                          or snowdond@uk.ac.man.cs

  The Devil may care... But I don't mind (T.S.o.M.)
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: The FAQ is on its way?
Date: 29 Sep 92 17:22:27 GMT
Article-I.D.: athena.1992Sep29.172227.19632
Organization: none, at the moment

In article <kauffman.19.717717505@slab.unt.edu>, Don Kauffman
(kauffman@slab.unt.edu) writes:
>	I keep reading that the FAQ is on its way, and I keep
>	waiting for it to be posted, but I never see it.

The comp.lang.c FAQ (frequently-asked questions) list is posted
monthly, on or about the first of each month.  It is also posted
in abridged form twice a month, on the first and the fifteenth.
The lists are crossposted to comp.lang.c and news.answers (the
net-wide FAQ list repository), with unlimited distribution.  As
far as I know, the lists are properly received at most if not all
sites worldwide.

Aside from premature expiration (which is an individual site's
own problem), there is one factor which could preclude a site's
receipt of the full comp.lang.c FAQ list: it is quite large, over
100k.  It is said that there are sites which reject articles
larger than 64k; the various guidelines and FAQ lists in
news.announce.newusers recommend not exceeding 64k in one
article [note 1].

If anyone reading this message has already or is able to
determine that for any reason their site does not receive the
comp.lang.c FAQ list (it never appears in comp.lang.c or in
news.answers, and the problem is not simply that it is
prematurely expired [note 2]), I would very much like to know
about it, especially if there is anything I can do about it.
(If a site never even receives the abridged list, the problem may
be worse than I had thought, because the abridged version of the
list is well under 64k, and should be getting through in any
case.)

					Steve Summit
					scs@adam.mit.edu

Note 1.  You don't need to suggest that I get around article size
constraints by splitting the full FAQ list up into pieces; I have
been steadfastly resisting this (obvious) suggestion for as long
as I have been posting the list.  A multi-part posting would not
only be more trouble for me to post, but also more trouble for
most readers to reassemble.

Note 2.  Premature expiry is a real problem for FAQ lists; many
sites apparently expire all articles quite rapidly, to conserve
disk space in the news spool directory.  FAQ lists in general
(and comp.lang.c's in particular) contain explicit Expires:
headers, in an attempt to keep them from being prematurely
expired.  Even if a site is forced to expire articles early, it
should strongly consider making an exception in the case of FAQ
lists, since they are intended to remain available all month as a
reference.  This is one reason that the newsgroup news.answers
was created -- it is moderated so as to guarantee that it only
contains bona-fide FAQ lists and other Periodic Informational
Postings (PIP's), and it is intended that the expiration policies
for news.answers can be set less conservatively than for the rest
of a site's newsgroups.
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 1 Oct 92 04:29:37 GMT
Organization: Pacific Software Group, Riverside, CA

In an article, steve@taumet.com (Steve Clamage) writes:
>[...] If realloc cannot shrink the size, it should do nothing; it should
>not attempt to make a smaller copy, for exactly the reason that it might
>fail.  It is not reasonable to fail on being asked to do less than has
>already been done. [...]

I have an issue with this last sentence. Consider a single-tasking operating
system with no VM. By forcing realloc() to always return successfully, the
program does not know if the memory that it was using has *actually* been
released. I could imagine that this would be an issue for "terminate and stay
resident" programs and their ilk.

IMHO, folks who write code like "chunk = realloc(chunk, small_buffer_size)"
and never check what's returned (and squash the pointer to a valid block of
core in the process) get exactly what they deserve.

-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (714) 681-2623
Pacific Software Group, Riverside, CA
Newsgroups: comp.lang.c
From: Elvis P.@graceland.rock.and.roll
Subject: Memory Allocation Question
Organization: Rose-Hulman Institute of Technology
Date: Thu, 1 Oct 1992 06:17:58 GMT


I have a thing that I want to allocate memory for as follows:

	int *thing[2];

First of all, I think this means an array of how ever much space I  
allocate, with 2 fields.
ie.  thing[100][0] and thing[100][1]

Well, how do I allocate memory for it?

Sorry if this is a stupid question.

__________________
Barry Trottier
e-mail:  trottibw@nextwork.rose-hulman.edu
From: ray@astro.ocis.temple.edu (Ray Lauff)
Newsgroups: comp.lang.c
Subject: Is there is (pascal) WITH equivalent in C?
Date: 26 Sep 92 07:03:03 GMT
Organization: Temple University
X-Newsreader: Tin 1.1 PL5

When programming in (sigh) Pascal there is a WITH statement which
allows all the references to a structure to be referenced without
repeating the struct variable name.  Is there such a thing in C?
I don't believe there is, but I may be wrong...

Thanks.  
Ray@astro.temple.edu
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: ++i = i++ ?
Date: 1 Oct 92 18:04:59 GMT
Organization: negligable

In article <BvEK4w.MrL@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
>
>In article <325@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
>
>|> That's what he said.  Not very useful, but syntactically correct.
>|> (with the possible exception of the missing ';', so you would
>|> actually have to write:
>|> 	for (i=0; i<Count, i++; )
>|> for the compiler to buy it....
>
>The compiler buys (or *should* buy) the pre-increment version just fine.

It wasn't pre- vs. post-increment that I was talking about,
but the missing semicolon in the "for" statement in the original
example.



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Work away today, think about tomorrow.		|
Never comes the day, for my love and me.	|	-Richard Hartman	
I feel her gently sighing			|	hartman@uLogic.COM
as the evening slips away....			|

Newsgroups: comp.lang.c,comp.lang.c++,comp.std.c,comp.std.c++
From: amorgan@csd-d-5.Stanford.EDU (Crunchy Frog)
Subject: Re: NULLing a pointer and INT 0x1c
Originator: amorgan@csd-d-5.Stanford.EDU
Organization: /usr/lib/news/organizatoin
Date: Mon, 5 Oct 1992 23:43:14 GMT

In article <92279.185945KSADEGH@auvm.american.edu> 
  Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
>Hi guys,

Salutations.

>1- how do you change the value of a pointer passed to a subroutine? It seems
>to me like you can do almost anything with it except changing the value
>to NULL. This is what I mean:

Let me ask you a question: I have a frobznick.  How do I change the value
of the frobznick in a subroutine?  I pass a pointer to it.  How, then, do
I change the value of a pointer?  I pass a pointer to that pointer.


main()
{
  int *fred;

  changeMe(&fred);
}

changeMe(int **thing)
{
  *thing = NULL;
}

I have no idea on your second problem.

C Frog
From: rrooks@ecs.umass.edu (Raymond Rooks)
Newsgroups: comp.lang.c
Subject: Passing values and function pointers
Date: 28 Sep 92 03:16:15 GMT

   I am having a problem with a routine that I copied out of Numerical
Recipies in C.  The routine rtnewt (for newton rhapson root finding)
reqires that a function pointer be passed to it.

   I am using what I saw in "Turbo C - The Complete Reference" to write
a main() that calls the rtnewt subroutine.  This reference I am using
says that to declare this function pointer I have to declare the function,
declare a character pointer, then cast the function to the pointer..ie

  int function();
  char *p;

  p = (char *) function;

so then I can then pass this pointer to the rtnewt.  The subroutine
rtnewt has four arguments, the first being the pointer to the function,
then three floats...which I guess is called like:

rtnewt(p,x1,x2,xacc)  (where the last three are floats, not pointers to
floats)

The problem I am having is that I cannot seem to pass the three floats
to the subroutine...the values are somehow 'lost'.

I thought that the problem might be fixed by prototyping, but I cannot
seem to figure out what the prototype should be.

--------

I had a similar problem previously, where prototyping solved the problem
of the subroutine not accepting the function arguments from the calling
subroutine.  What is the big deal with this? 

Ray
(please reply in mail if you can)

Newsgroups: comp.lang.c
From: "hans friedrich steffani" <GM08@DKAUNI2.BITNET>
Subject: looking for portability- and good-style ruules
Organization: University of Karlsruhe, Germany
Date: Wed, 30 Sep 1992 14:28:07 GMT


within a new EC-project with many partners on many sites
we are looking for a collection of rules to do 'good', well
documented and portable programming in C.
Where can i get this?
Hans Friedrich Steffani
Uni Karlsruhe
Germany
Newsgroups: comp.lang.c
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Subject: Re: enum type and case statements
Organization: The Johns Hopkins University CS Department
Date: Sat, 3 Oct 1992 07:39:53 GMT

In article <2775@bsu-cs.bsu.edu> pickens@bsu-cs.bsu.edu (David B. Pickens) writes:
>
>This did not work needless to say.  So I switched my train of thought
>to using enum and setting up something like this:
>
>enum command {AG=1,AV,.......,ZZ} arg;
>
>main ()
>{
>
>...........
>
>		switch(arg)
>		{
>			case 1:
>				command_ag();
>				break;
>			case 2:
>				command_av();
>				break;
>			...........
>			default:
>				command_err();
>				break;
>		}
>
>My question is this, if I go this route, how in the world of c do I
>convert my two/three character string and get the right enum?
>
>Any ideas out there?
>

One way to do it is to define an array of strings, i.e.

char *CommandStrings[] = { "AG", "AV", ... "ZZ" };

(Note that the index of "AG" is 0 not 1).

You could then find the string in the array and use the index in
your case statement.  Of course, unless there are enough strings
to make a binary search worthwhile, this isn't any better
than just using if statements instead.  

This is also very fragile, inserting a new command in the middle
of the array will change some of the indices.  You could make it
more flexible by using an array of this structure instead:

struct {
   char *Command;	
   int  CommandNum;
}

Again, unless you have a large number of strings, this is no better
than a bunch of if statements.  What IS an improvement is to do 
this:

struct {
   char *Command;
   void (*CmdFun)(void);
} CommandTable[] = { { "AG", command_ag }, { "AV", command_av }, ...
                     { "ZZ", command_zz } };

const int NumCommands = sizeof(CommandTable)/sizeof(*CommandTable);

So CmdFun points to the function associated with Command.

Your switch statement can be replaced with:

i = 0;
while (i < NumCommands && strcmp(CommandArg, CommandTable[i].Command)) {  
	i++;
}

if (i == NumCommands) { /* not found */
   command_err();
}
else {
   CommandTable[i].CmdFun();
}  

[Aside: As Steve Summit points out in the FAQ, using strcmp directly
can be confusing because of the non-intuitive return values, i.e. 0
indicates equality.  You might want to "#define streq(x,y) !strcmp(x,y)"]

Unlike using a switch or if statement, this does not require
change if you change the command set, only the CommandTable
array must be modified.

Finally, you could build an FSA to recognize the set of 
command strings, if you have enough strings to warrant doing
so.

-Dwight

Newsgroups: comp.lang.c
From: djaschbr@iastate.edu (David J Aschbrenner)
Subject: Determining variable type at run-time (followup q.)
Organization: Iowa State University, Ames, IA
Date: Thu, 1 Oct 1992 04:52:15 GMT


First of all, I would like to express my thanks to those who took the time to
respond to my original question (you know who you are).

The most common response I received indicated that unions might be the way to
go and I shall have to explore this solution.

However, for now, the responses I received have inspired another idea, and I
would like your analysis. The idea looks something like this:

	struct foo {
		char type; /* type = 0 for char, 1 for int, 2 for char *, etc*/
		void *value; /* this is a ptr to the actual value */
	};

	main()	{
		struct foo x;
		char	c = 'a';
		int	i = 456;
		char	*str = "this is a string";

		x.type = 0;
		x.value = (void *)&c;
		OutPut(x);

		x.type = 1;
		x.value = (void *)&i;
		OutPut(x);

		x.type = 2;
		x.value = (void *)str;
		OutPut(x);

		exit(0);
	}

	void OutPut(struct foo in)	{
		
		switch(in.type)	{
			case 0:
				printf("%c\n", (char)in.value);
				break;
			case 1:
				printf("%d\n", (int)in.value);
				break;
			case 2:
				printf("%s\n", (char *)in.value);
				break;
		}
		return;
	}


Please forgive any syntactical or obvious logic errors. Anyway, the output
desired is:
	
	a
	456
	this is a string

Will this work? Is there a more efficient/better way to do this?


			Thanks again,
			David Aschbrenner

BTW, this question is derived from a need for a variable number of variables
of undefined type (undefined at compile-time, that is). Basically, its for
a database program.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: can != be used in compound if
Date: 30 Sep 92 18:56:32 GMT
Organization: negligable

In article <1992Sep30.083323.29522@bristol.ac.uk> P.Smee@bristol.ac.uk (Paul Smee) writes:
>In article <1992Sep28.194631.25334@julian.uwo.ca> operator@julian.uwo.ca (Operator) writes:
>>rnum is a random number generated by random().
>>number_set[] is an array of 6 integers.
>>
>>if (rnum != number_set[1] && rnum != number_set[2] && rnum != number_set[3])
>>
>>is this if statement correct, if not, what is wrong with it????
>
>Nothing wrong with that statement per se, looking at it in isolation.

And, as a general comment on style it is usually helpful to type 
compound expressions w/ extra parenthesis:

	if ((rnum != number_set[1]) && (rnum != number_set[2]) && 
		(rnum != number_set[3]))

In this case it would not make a difference, but it helps clarity
and w/ some operators you would need parens to make it come out 
right, e.g. 

	if (fp = fopen(...) == NULL)
		fprintf(stderr, "oops\n");

would have a problem fail because the == is evaluated before the =
and you would compare the return value of fopen() to NULL, then
assign the result (true or false) to fp, then the next time you
use fp (fprintf(fp, "this is data\n");) your program would blow
up.

	if ((fp = fopen(...)) == NULL)

ensures that the assignment occurs before the comparison and
that fp will be valid later on.

Similar things can happen w/ dereferencing pointers and (I think)
some of the binary operators (^, |).  In general if it might be
misunderstood by either the compiler OR someone reading the program
toss in a few extra parens -- it just makes life easier.

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"186,000 mi/sec.  Not just a good idea, it's the LAW!"

Newsgroups: comp.lang.c
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Determining variable type at run-time
Date: 30 Sep 92 22:03:25 GMT
Article-I.D.: ulogic.345
Organization: negligable

In article <1992Sep29.213615.23779@news.iastate.edu> djaschbr@iastate.edu (David J Aschbrenner) writes:
:
:I am curious as to whether it is possible to do something like the following:
:
:main()	{
:	int i;
:
:	scanf("%d", &i);
:	switch(i)	{
:		case 0:
:			char a;
:			break;
:		case 1:
:			int a;
:			break;
:
:		/* other cases */
:	}
:	/* rest of program which does something with a */
:}
:
:Is this possible? (I do need 'a' to have scope throughout main())
:If I can't do this, is there another way to accomplish my goal?
:
:			Thank you,
:			David Aschbrenner

No.

Why would you want to?

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I am just a figment of your imagination...
			...what does that say about *your* mental health?
Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Determining variable type at run-time (followup q.)
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 1 Oct 1992 12:53:34 GMT

djaschbr@iastate.edu (David J Aschbrenner) writes:

>The most common response I received indicated that unions might be the way to
>go and I shall have to explore this solution.
>
>However, for now, the responses I received have inspired another idea, and I
>would like your analysis. The idea looks something like this:
>
>	struct foo {
>		char type; /* type = 0 for char, 1 for int, 2 for char *, etc*/
>		void *value; /* this is a ptr to the actual value */
>	};

Use an enumeration (instead of magic numbers 0, 1, 2, etc.) for the type,
and a union (instead of a void *) for the value.

-- 
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!
Newsgroups: comp.lang.c,comp.lang.c++
From: guenther@stolaf.edu (Philip Guenther)
Subject: Re: Help!! with flex/byacc on Borland C
Organization: Academic Computing Center, St. Olaf College
Date: 6 Oct 92 13:14:44

In <s912121.718333321@minyos.xx.rmit.OZ.AU> s912121@minyos.xx.rmit.oz.au (Joydip Das) said:

<intro to problem deleted>
   Anyway, I was attempting to compile flex with the ANSI C and portability
   options turned on as this is vital for the work I want to do with flex/byacc
   (future portability to others OS).  When I try to compile the sources, I get
   a lot of warnings about undeclared prototypes.  As far as I can tell, these
   have been declared in flexdef.h  .
   There is also a compiler directive in flexdef.h as follows:
       #ifndef PROTO
       #ifdef __STDC__
       #define PROTO(proto) proto
       #else
       #define PROTO(proto) ()
       #endif
       #endif

This is a tricky method to allow the same function declarations to
work with both ANSI and K&R C.  What happens is that if PROTO hasn't
already been defined, the it is here.  __STDC__ is defined only in
ANSI C.  So that if this is ANSI C, then all those function
declarations have parameter typing (The "PROTO" and outmost set of
parens is stripped off).  If you are using K&R C ('traditional'), then
the whole "PROTO ((foo))" is replaced with just parens, for K&R style
function declarations.  Pretty sneaky, eh?

   I am not sure what this definition is for.  Subsequently there are prototypes 
   declared within flexdef.h such as:
   extern void ntod PROTO(());
   and 
   extern void make_tables PROTO(());
                                ^^^^
This is sort of silly.  It should be ((void)) instead, so that
make_tables(void) is given to ANSI compilers, and make_tables() is
given to K&R only, not both.

   etc.
   and also in the sources, e.g. in main.c there is
   void flexinit PROTO((int, char**));

   These prototypes do not seem to be recognisable to the compiler.
   I am really confused.  Am I doing something stupid or is there something I
   don't understand about language/compiler/flex/byacc ?

It sounds like either __STDC__ is defined when it shouldn't be, or
that you are passing -DPROTO or some such (that would disable the
replacement, and you would end up with an extra set of parens around
everything) to the preprocessor.

   If anyone can help me with this I would be really grateful.  If anyone has
   actually compiled flex and byacc as I am attempting to do, I would really
   appreciate a guiding light.

Hope that makes thing a little more understandable.  I'm not sure I
actually helped you with your problem... :-)

   J.D
   -----------------------------
   m912121@chudich.co.rmit.OZ.AU

Philip Guenther
--
guenther@stolaf.edu (Philip Guenther)       | The ACC might agree with me,
Student Sys Prog, Academic Computing Center | but with that bunch, (and me)
St Olaf College, Northfield, MN 55057-1001  | you never know... :-) :-| :-(
"Life makes sense?  LIFE MAKES SENSE!!?  Where do people get these ideas?"-me
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: unpredictable post-decrement behavior., also ++i = i++ ?
Date: 1 Oct 92 18:07:52 GMT
Organization: negligable

In article <1992Sep30.164634.7394@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>
>These descriptions are misleading.  One cannot say with precision
>when the increments (resp. decrements) performed by ++ (and --)
>are performed, except that they must occur between the previous
>and following sequence points.  ("Sequence point" is a term which
>is precisely defined in the ANSI C Standard; for our purposes, it
>is basically an edge of a simple statement or full expression.)
>In particular, "i++" does *not* mean "fetch i's value, then
>increment i, then proceed with the rest of the expression."
>Since the increment can occur at any later time, prior to the
>next sequence point, it's undefined what happens if other parts
>of the expression also reference i.

Actually I would have translated that as "fetch i's value, proceed
with the rest of the expression, then increment i".  But it is
equally as wrong, apparently.

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Badges?  I don' got to show you no stinkin' badges!"