HDTenEightyP/NetNews huggingface dataset:
From: chuwchon@anu.edu.au (wing chu )
Subject: Re: Pascal 2 C
Reply-To: chuwchon@anu.edu.au
Organization: Australian National University
Date: Mon, 28 Sep 92 09:22:50 GMT

In article

28SEP199200161355@vtcc1.cc.vt.edu, alfaroja@vtcc1.cc.vt.edu (L. D. ROPER) writes:
>I am looking for a Pascal to C converter.  Thanx in advance...
>
>Alfaroja@vtcc1.cc.vt.edu

A Pascal to C converter (p2c) availiable from csvax.cs.caltech.edu by anonymous ftp.

chuwchon@mehta.anu.edu.au


Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: C-formattors (problems with very long lines)
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 29 Sep 1992 13:18:21 GMT

hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:

>I wrote my own simple "C-beautifier", which simply does the
>following:
>
>   - discard empty lines
>   - insert a '\n' after each ';' found
>
>This works fine, but now I have 2 questions:
>
>  1. Is this a correct transformation of any C-Source ?

No. You need to make sure that you don't insert newlines into string
or character literals that may contain semi-colons.

-- 
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
From: books@fsunuc.physics.fsu.edu (Roger Books)
Subject: Re: about foo and bar
Organization: FSU nuclear physics
Distribution: usa
Date: Mon, 5 Oct 92 12:42:57 GMT

In article <1apbjtINNbl6@function.mps.ohio-state.edu> ren@function.mps.ohio-state.edu (Liming Ren) writes:

>
>Pardon my igronace!
>
>I see many c book authors using the function names such as foo and bar.
>Any story about them ? They must be some funy meaning associated with them.
>What are they?

The actual spelling of the acronym is FUBAR.  The PC meaning is
Fouled Up Beyond All Recognition.  I'll leave it to you to figure out
what the original military acronym was.  Oh, it is pronounced foo-bar.

Oh, by the way, this should not have been posted here.  I'll leave it to
someone else to say where it should go and possibly flame me for answering.
If I knew where it was supposed to go I would tell you.

Roger
books@fsunuc.physics.fsu.edu
Newsgroups: comp.lang.c
From: rscott@spock.NMSU.Edu (Joseph Good)
Subject: Bus Error???
Organization: New Mexico State University
Date: Wed, 30 Sep 1992 23:46:45 GMT


ACK!!

I have been away from programing C for Unix for a couple years, 
and now can't seem to fix a simple problem..

I am trying to make a NFF to Rayshade 4.0 file converter, and for some
stupid reason, I keep getting a nice BUS ERROR message after
everything is compiled and done.

It happens when i try to read from the file, no matter what function I use.. be  
it fscanf.. fgets..  anything --> bus error.


Here is the functions...

int
view(name)
	char           *name;
{
	FILE           *infp;
	char            head[20];
	int             val = 0,
	                a1 = 0,
	                a2 = 0;
	float           arg1 = 0.,
	                arg2 = 0.,
	                arg3 = 0.;

	printf("Opening %s for viewing data.\n", name);

	infp = fopen(name, "r");
	if (!infp) {
		perror(name);
		exit(-1);
	}
	
	printf("Getting the viewing data.\n");

	while (!feof(infp)) {
		fscanf(infp, "%s %f %f %f", head, arg1, arg2, arg3);
		printf("head = %s %f %f %f\n", head, arg1, arg2, arg3);
		fseek(infp, 80, SEEK_CUR);
	
		if (strcasecmp(head, "v") == 0) {
			printf("the V is still there.\n");
			printf("%s (ain't it fun!)\n", head);
			val = 1;
		} else if (strcasecmp(head, "from") == 0) {
			printf("the FROM case is working\n");
			printf("%s %f %f %f\n", head, arg1, arg2, arg3);
			val = 1;
		} else if (strcasecmp(head, "at") == 0) {
			printf("the at case is working\n");
			val = 1;
		} else if (strcasecmp(head, "up") == 0) {
			printf("the up case is working\n");
			val = 1;
		} else if (strcasecmp(head, "resolution") == 0) {
			printf("the resolution case is working\n");
			val = 1;
		} else if (strcasecmp(head, "hither") == 0) {
			printf("the hither case is working\n");
			val = 1;
		} else if (strcasecmp(head, "angle") == 0) {
			printf("the from case is working\n");
			val = 1;
		} else {
			printf("Unknown case %s.\n", head);
			val = 0;
		}

	}

	fclose(infp);
	return (val);
}

The file format is like:

string float float float

and the string does't get larger than 20 characters...

I'm out of ideas tonight.. and my old moldy C manual isn't any help.

Thanks!

joe

--

Joseph Good
+-------------------+ - More than just a band....
| Green Dot Brigade | - It's a whole damn army of dots...
+-------------------+ - And we've declared war on the 7-Up dots...

rscott@nmsu.edu (NeXT mail welcome!!) (main account)

atlantis@acca.nmsu.edu  (Just plain ol' Unix) (seldom used)
Xref: sparky comp.lang.c:14383 comp.lang.pascal:5760 comp.lang.misc:3199
From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.lang.c,comp.lang.pascal,comp.lang.misc
Subject: Re: SUMMARY: Preferences toward case sensitivity/insensitivity
Date: 1 Oct 92 14:59:19 GMT
	<id.IBNT.KP8@ferranti.com> <1992Sep29.162158.5929@ima.isc.com>
Reply-To: spackman@dfki.uni-sb.de
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken

In article <1992Sep29.162158.5929@ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:

|I'm not sure I agree that this would "resolve all remaining complaints".
|It's not uncommon for C programmers to use a lowercase name for a variable
|whose *type* has the same name capitalized, e.g.  |Thing thing;| (this is
|usually either a local variable with short scope, or a global variable
|representing the only instance of the type), and I expect some people would
|be miffed at getting a warning for this.

In fact my personal belief is that a language ought to REQUIRE that type
names begin with captials and instance names with lowercase. That done,
it is hard to imagine a case where one would write foo and mean Foo, or
vice-versa - or for that matter, one where the error would not be caught
by the usual mechanisms of the language.

If we're willing to question whether case should be significant in
identifiers, shouldn't we also ask whether spaces should be permitted
within tokens, or whether , and ; shouldn't be treated identically?
Perhaps all the "extra symbols", !@#$%^&*~`, should count as different
capitalisations of the same underlying letter? After all, the difference
between # and @ is at LEAST as hard to remember as that between a and A.
The distinction between a and A is one you make ten times in every
sentence you ever type, after all!

------------------------------------------------------------------------
stephen p spackman                                       stephen@acm.org
------------------------------------------------------------------------
Xref: sparky comp.lang.c:14280 sci.space:13743
From: fletcher@saxon.UUCP (Edward F Eaglehouse)
Date: Sun, 27 Sep 1992 12:04:43 +0200
Organization: Auldhaefen Associates
Newsgroups: comp.lang.c,comp.unix.progammer,sci.space
Distribution: world
Reply-To: efe@aldhfn.akron.oh.us (Edward F Eaglehouse)
Subject: Re: Easter
	<DM.92Sep24220600@stekt2.oulu.fi>
X-Newsreader: Ann 0.9
Reply-To: ciaran@aldhfn.akron.oh.us
Reply-To: aldhfn!ciaran

I don't have any actual code to calculate Easter, but if I remember
correctly Easter falls on the first Sunday following the first full moon
after the Vernal Equinox.

An astronomical programmer should be able to provide this one.  Somebody in
sci.space probably can give us a formula.
-- 

::Ed
::ASC -- Automated Solutions Corporation

--- via InterNet/Usenet ---|-- via UseNet --| "I know my own mind, and
  efe@aldhfn.akron.oh.us   |   aldhfn!efe   |  it's around here someplace"
Automated Solutions Corp.  |                | -- seen on a T-shirt
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Problem using fseek
Keywords: file operations
Date: 2 Oct 92 17:59:56 GMT
Article-I.D.: ulogic.371
Organization: negligable

In article <1992Oct2.030809.26674@mnemosyne.cs.du.edu: ghuntres@nyx.cs.du.edu (Gary  huntress) writes:
:
:Is there any reason why the following wont work (IBM PC w/ msc 6.0)
:fh=fopen("foo.dat","a");
:if(fh==NULL) exit(-1);
:fseek(fh,-5L, SEEK_CUR);
:It just sits at EOF!  It does not rewind.
:
:Maybe I can give a better description of what I'm trying to accomplish.
:I've got a long unstructured activity log called by many procedures
:The contents of each line (i.e. number of entries ) will vary 
:depending on the message that is written:
:
:  1024  TIMECODE ALTITUDE SPEED ERRORCODE
:  2020  TIMECODE BUS_VOLTAGE BUS_TEMPERATURE ONLINE TESTCODE
:  2022  COMMAND COMMAND_STAT COMMAND_QUEUE RESULT
:
:hopefully you get the idea.  The first string will identify the format 
:of the rest of the line.  I want to open the file and parse the LAST line
:
:I figured that the best way to do that would be to open in append mode, 
:moving backwards looking for the last \n and then read in strings.
:
:Questions:
:
:  1)  Can I seek backwards through a file opened for append?
:  2)  Is there an incredibly obvious solution to this problem 
:      that I completely overlooked? 
:
:mucho thanks,
:Gary Huntress          while(TRUE){edit(); compile(); link(); run()}D
:C


"Append" is a special case of "write".  No matter what you can
or cannot do w/ positioning the file pointer you would not be
able to read from that file.  Try opening it w/ "rw" access.

		-Richard Hartman
		hartman@uLogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Ideas are not responsible for the people who believe them."
Newsgroups: comp.lang.c
From: cs125b52@ih-nxt01 (cs125 student)
Subject: Stack Overflow ( HELP PLEASE )
Organization: University of Illinois at Urbana
Date: Sun, 4 Oct 1992 23:44:46 GMT

     I'm using a recursive function to mimic "floodfill" for SVGA. 

Unfortunately, my new function keeps giving me a stack overflow.  How do I

increase the stack?  Could anybody give me a hint?  I've tried different

memory models and everything else I could think of. 

     The procedure can't really be using up all available memory cuz the

procedure only fills about 1000 pixels before it overflows.
  

Bor-Tyng Lin
(cs125b52@ih-nxt01.cso.uiuc.edu)
Please mail me as I don't read this group often.
Newsgroups: comp.lang.c
From: jmolinari@hamp.hampshire.edu
Subject: Re: can != be used in compound if
Organization: Hampshire College
Date: Thu, 1 Oct 1992 15:41:43 GMT

> 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????
> 

	You need to separate the different concepts in the IF statement with
()'s.  Thus:

	if ((rnum != number_set[1]) && (rnum != number_set[2])
&& (rnum != number_set[3]))  {                                ^^^It doesn't fit
...                                                              on the same
}                                                                line here, but
                                                                 it has to be
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Differences between ANSI C and VAX C
Organization: TauMetric Corporation
Date: Fri, 2 Oct 1992 16:12:10 GMT

mad@spirit.clearpoint.com (Michael Davis) writes:


>I hope I'm not too late to be of use--I don't read comp.lang.c very
>often.  Anyway, one thing that bit me is that global variables are all
>UPPERCASED during compilation.  If you have a function FooBar and a
>variable foobar, which should be distinct, VAX C will barf.

While this is certainly an inconvenience, it is allowed by ANSI C.
Section 3.1.2, Identifiers:

"The implementation may further restrict the significance of an
external name (an identifier that has external linkage) to six
characters and may ignore distinctions of alphabetical case for
such names."
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: rgasch@nl.oracle.com (Robert Gasch)
Newsgroups: comp.lang.c
Subject: FAQ wanted
Date: 5 Oct 92 16:30:05 GMT
Organization: Oracle Europe

The full-length FAQ still has not made it to my site so I'd appreciate
it if someone could send me a copy or point me to an FTP archive.
Just to clarify: I'm looking for the full-length FAQ, not the abriged
version.


Thanks
---> Robert
rgasch@nl.oracle.com
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: C solution to Magic Square
Organization: TauMetric Corporation
Distribution: na
Date: Sat, 26 Sep 1992 16:22:40 GMT

landolt@nexus.yorku.ca (Paul Landolt) writes:

>One of my associates is being highly productive and trying to solve a magic
>square.

>He is attempting a brute force method of solving the puzzle: Random guessing
>with the computer (ugh!)

>My question is: Is there a simple(r) mathematical method of solving the
>magic square for any size? Anyone? Any ideas? Has anyone seen C source that
>will do this?

Books on mathematical games and puzzles often contain algorithms for
solving magic squares.  There are two general solutions, one for
squares of odd order, another for those of even order.  I'll present two
algorithms, leaving the programming as an exercise for the reader.

For odd order:

From a starting point, number the boxes in numerical order: 1, 2, 3, 4, ...
After placing one value, place the next value in the box diagonally
upward and to the right.  If this would fall off the right side of
the square, put the value in the leftmost column (i.e. columns wrap
around).  If the location would fall off the top of the square, put
the value in the bottom row (rows wrap around).  If you are in the
upper right corner or if the box you need is already filled, put
the value imediately to the left.  Start in the box in the middle of
the rightmost column.

Here is the solution for 5x5:
  9   3  22  16  15
  2  21  20  14   8
 25  19  13   7   1
 18  12   6   5  24
 11  10   4  23  17


For even order:

Draw the two diagonal lines.  Starting in the upper left, proceeding
left to right, top to bottom, write the number of each box in the box,
except that you don't write any number in a box with a line drawn in it.
After this step, a 4x4 square looks like this:
	 .   2   3   .
	 5   .   .   8
	 9   .   .  12
	 .  14  15   .
Go back to the top left, and fill in the omitted boxes counting backwards:
	16   2   3  13
	 5  11  10   8
	 9   7   6  12
	 4  14  15   1

I'm presenting these from memory.  I actually wrote a program for the
odd-order algorithm and tested it up to 99x99.  If the even-order
algorithm doesn't always work, you can get your money back by
returning the unopened package postpaid.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Xref: sparky comp.lang.c:14334 comp.lang.c++:14359
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Some simple C advice needed..
Date: 30 Sep 92 21:34:39 GMT
Article-I.D.: ulogic.341
Followup-To: comp.lang.c
Organization: negligable

Turbo C includes it's own library of graphic routines (the Borland Graphic
Interface library -- or BGI library for short if I remember correctly).

If you're using Borland that may be your easiest bet.  Otherwise you get
into manipulating the screen memory directly & w/ the bit-plane orientation
of *some* of the EGA/VGA graphic's modes this can really be a pain if you
don't have to deal with it.

Otherwise, I'd recommend a book called (oh heck, it's not in my bookcase
after all, well I *think* it's called): Programming the EGA/VGA.

If your after supervga call your card manufacturer & order a programming
reference for it -- different svga cards may use different methods for
their higher resolution modes.

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Badges?  I don' got to show you no stinkin' badges!"
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: ++i = i++ ?
Date: 30 Sep 92 15:47:50 GMT
Organization: negligable

In article <1992Sep30.021928.1456@waggen.twuug.com> alpha@waggen.twuug.com (Joe Wright) writes:
:Gary Merrill (sasghm@theseus.unx.sas.com) wrote:
:: 
:: In article <1992Sep28.184140.4116@kpc.com>, hollasch@kpc.com (Steve Hollasch) writes:
:: |> 
:: |>     I'll assume that you made a typo here and really meant to say
:: |> 
:: |>         for (i=0; i < Count; ++i)
:: |>                            ^ A comma here is a syntax error.
:: 
:: Well, since no one else pointed this out, and in order to forestall
:: additional errors and confusion ...
:: 
:: A comma here is *not* a syntax error!  The syntax error is
:: 
::          for (i=0; i < Count, ++i)
::                                  ^
::                                  missing ';'
:: 
:: Now I admit that
:: 
::          for (i=0; i < Count, ++i; )
:: 
:: would be pretty unusual code, but it is *syntactically correct*.
:: (And indeed, there *are* cases when one might *want* a comma
:: operator in the middle clause.)
:: -- 
:I don't think so.  The comma operator separates two statements and
:ensures the statements are evaluated left to right.  Using the above
:'i < Count, ++i;' as a for control will ignore the 'i < Count' and
:return the ++i condition.  The condition will be 'true' until i goes
:from -1 to zero.  Not very useful.

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

Which is why I assumed the comma was a typo entering the message,
and not in the actual program the original question was about....)


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
And when you stop and think about it	|
(you won't believe it's true)		|	-Richard Hartman	
That all the love you've been giving	|	hartman@uLogic.COM
has all been meant for you.		|
From: gegu@zurich.spectrospin.ch (Gerry Gucher)
Newsgroups: comp.lang.c
Subject: Re: Lint Puzzler
Summary: main should return a value
Date: 27 Sep 92 18:08:20 GMT
Organization: Spectrospin AG, Fallanden Switzerland

In article <1992Sep24.212540.2625@mccc.edu>, pjh@mccc.edu (P. J. Holsberg) writes:
> The Software Development System is SCDE 5.0 on SVR3.2.2.
> 
> Here's the program:
> 
> /*simple.c*/
> 
> #include <stdio.h>
> main() 
> {
>   int num;                /* define a variable called num */
>   
>   num = 23;               /* assign a variable called num */
> 
>   printf ("I am a simple ");
>   printf ("computer.\n");
>   printf ("My favorite number is %d because ", num);
>   printf ("it is first.\n");
> }
> 
> And here's what lint says about it:
> 
> 
> function falls off bottom without returning value
>     (13) main       

Put a  return 0; or more ANSI conformant return EXIT_SUCCESS; at the
bottom of main. main() is a function that returns an int and without
an explicit return an arbitrary value is returned to the invoking shell,
which is something you want to avoid to allow shell scripts to work
properly.

> 
> name declared but never used or defined
>     _iob             	stdio.h(85)

Usually there is a lint option (-u on SunOS) to supress warnings about
declarations that are never used. This is an option you want to use
in any case if you have the good habit of putting declarations in 
header files, because you will always find unused declarations in this
case.
 
> 
> value type declared inconsistently
>     fopen            	llib-lc:stdio.h(147) struct <no-tag> *() :: stdio.h(86) struct <no-tag> *()
>     fdopen           	llib-lc:stdio.h(207) struct <no-tag> *() :: stdio.h(86) struct <no-tag> *()
>     freopen          	llib-lc:stdio.h(148) struct <no-tag> *() :: stdio.h(86) struct <no-tag> *()
>     popen            	llib-lc:stdio.h(208) struct <no-tag> *() :: stdio.h(86) struct <no-tag> *()
>     tmpfile          	llib-lc:stdio.h(143) struct <no-tag> *() :: stdio.h(86) struct <no-tag> *()
>     fread            	llib-lc:stdio.h(177) unsigned int () :: stdio.h(90) int ()
>     fwrite           	llib-lc:stdio.h(179) unsigned int () :: stdio.h(90) int ()
> 

No clue, seems to be a follow up error of previous bugs, or you didn't
give us all the relevant code.

> function returns value which is always ignored
>     printf          

(void) printf("...");  will fix this.

BTW, defining

/*ARGSUSED*/
int main(argc, argv)
int argc; char *argv[];
{
  /* ... */
}

is a good idea, because main really gets these arguments, wether
you use them or not.


Gerry

+------------------------------------------------------------------+
| Gerry Gucher                             gegu@spectrospin.ch	   |
| Spectrospin AG,  Industriestr 26,  8117  Faellanden Switzerland  | 
+------------------------------------------------------------------+
| A program that  returns the  wrong | There is nothing wrong with |
| result twice as fast is infinitely | making  mistakes,  but make |
| slower.               - H. Spencer | new ones.           - D.Sim |	
+------------------------------------------------------------------+
Newsgroups: comp.lang.c
From: ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke)
Subject: Re: Is there is (pascal) WITH equivalent in C?
Organization: University of Karlsruhe, Germany
X-Newsreader: Tin 1.1 PL4
Date: Thu, 1 Oct 1992 11:45:17 GMT

jos@and.nl (Jos Horsmeier) writes:
> 
> May I strongly suggest _not_ to use such macros, they're obfuscating 
> the code. Just imagine what would happen if other structs happen to
> have elements with the same names (bar and baz.) IMHO the WITH construct
> in Pascal is silly, it just saves a couple of keystrokes, ... 
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                      ||||||||||||||||||||||||||||||||||||

That's just not true. Most non-optimising compilers would generate better
and faster code from a WITH construct than from the corresponding construct
without WITH.
They would calculate the base address of the referenced RECORD variable
only once and then add the corresponding offset of a RECORD component
each time such a component would be accessed.
If you don't use WITHs such a compiler would repeat the base address
calculation for each variable construct that accesses RECORD components.
Therefore a construct like

  WITH a.b.c DO x := y + z;

is always better than writing

  a.b.c.x := a.b.c.y + a.b.c.z;



Peter Januschke
University of Karlsruhe, Germany

Newsgroups: comp.lang.c,comp.sources.wanted,comp.msdos.programmer,comp.misc
From: Nico Tranquilli <@>
Subject: Wanted: C-isam library for Turbo C or Microsoft C
X-Xxmessage-Id: <A7172BCBE0040B1C@mac3.di.unipi.it>
X-Xxdate: Fri, 30 Oct 92 22: 13:31 GMT
Organization: Dipartimento di Informatica, Universita' di Pisa
X-Useragent: Nuntius v1.1.1d9
Date: Wed, 30 Sep 1992 17:13:29 GMT

Does anyone have (or know where to find) C-Isam libraries for
Microsoft C 6.00 or Turbo C 2.0 compiler ?
Newsgroups: comp.lang.c