HDTenEightyP/NetNews huggingface dataset:
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Fortran to C conversion: Why bother?
Date: 13 Nov 92 07:06:41 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Nov9.131601.167@gems.vcu.edu>, hleaves@gems.vcu.edu writes:
  I was wondering why anyone would bother using the f2c (or similar) program
  to translate fortran code directly into C.

In order to compile it.  I have accounts on 7 or 8 UNIX systems in four
organisations at the moment.  They all have C compilers.  (In fact they
all have two: the vendor's and GCC.)  From time to time I have Fortran
code that I would like to run.  _One_ of the machines I have an account
on had a Fortran compiler.  But the vendor stopped supporting it in favour
of an unbundled one, and then it stopped working in the next release but one
of the operating system.  Even before that, I found that f2c followed by cc
was better.

GNU Fortran is currently in alpha test.  But until that's available,
f2c (free, in source form) + gcc (free, in source form) makes a usable
Fortran 77 system.  I don't care whether it's C or Serbo-Croat in between.

If there was a _reliable_ Pascal to C translator I'd use that too.
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Help.  (Unix C)
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Thu, 5 Nov 1992 06:33:44 GMT

scjones@thor.sdrc.com (Larry Jones) writes:
: An ANSI compiler will, quite properly, object to this code -- it is
: neither correct nor portable.  The comparison function *must* be
: defined with two "void *" arguments (or "char *" if your compiler is
: too old to support "void *"); that's what qsort calls it with.  Some
: implementations use the same representation for all pointer types and
: on those implementations you can misdefine the function and it will
: work, but this is not guaranteed and there are systems where it will
: fail.  
: 
   First of all, i don't use an ANSI compiler except for about 20%
of my code (the declaration of the function should have helped on that).
But, even on an ANSI compiler this will work. void is used to take on 
no predetermined meaning, or to actually mean return NOTHING from a 
function if used as a declaration type. malloc returns void *, but it
won't complain if you dont cast the return value and assign it to a 
char *. Also, the strcmp()  function is used QUITE OFTEN in qsort.
look at the definition for it though strcmp(const char*,const char*)
it doesn't have void * declared as you say a routine that qsort calls
*must* have.

And if the code were not portable, it compiles and works on a non-ansi
compiler (and all of the ANSI ones i tried), so please take back the
part where you say the code is not correct. it is.

Dave fuller
dfuller@portal.hq.videocart.com

Newsgroups: comp.lang.c
From: faivre@cst02.segin.com (Denis Faivre)
Subject: Re: macros: "same name/different number of arguments"
Reply-To: faivre%cst02.segin.com (Denis Faivre)
Organization: Segin, Groupe Axime
Date:  9 Nov 92 10:00:52 GMT

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


>Hello!

>The C-preprocessor has the disadvantage of not allowing
>the same macro-name for macros of different number of
>arguments.
[...]
>Below you can see my proposition for fixing this kind
>of problem: 

>  Define a macro which expands to a function-call
>  with one open bracket but without the closing one.
>  This "allows" a variable number of arguments; the
>  only disadvantage is, that you have to write one
>  more closing than opening bracket in the program.

>My questions now are:

>  - Is this portable/ANSI-conform ?

I don't know.

>  - Are there any reasons for not doing it this
>    way (style, ...) ?

At least one : with such a technique you might have trouble using
a C beautifier like GNU indent : it would certainly complain about
unbalanced parentheses... and abort.

Denis.
-- 
Denis FAIVRE - AXIME                   When anything can go wrong, it w$*& !
Phone : +33 20.60.79.79
E-Mail : faivre@cst02.segin.com
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: single formula for number of bits set in a byte
Date: 7 Nov 92 21:53:47 GMT
Organization: University of Helsinki

hartman@ulogic.UUCP (Richard M. Hartman) writes:
>I have never met a compiler that yields other than 1 and 0 for
>equality and relational expressions.

Even K&R-1 said that the result of a boolean expression is either 0 or
1, even though any non-zero value in a boolean context stands for
"true".  IMHO, any compiler which gets this wrong is seriously broken.

>For C++ compilers this is guaranteed in the ARM (p74, section 5.9).
>Unfortunately I don't have the ANSI C compiler document available
>but I would suspect this is guarenteed there also.

It is.  Don't have the standard itself, but "Standard C" by Plauger and
Brodie describes this behaviour for every boolean operator. 

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Newsgroups: comp.lang.c
From: vcsc538@sfsuvax1.sfsu.edu (J. Loh)
Subject: Indian Hill
Followup-To: jloh@futon.sfsu.edu
Summary: C Formats
Originator: vcsc538@sfsuvax1.sfsu.edu
Organization: San Francisco State University
Date: Thu, 12 Nov 1992 03:36:13 GMT

Does anyone know where I can find this paper?


Newsgroups: comp.lang.c
From: ae007@yfn.ysu.edu (Daniel Newcombe)
Subject: void pointer to a struct?
Organization: Youngstown State University/Youngstown Free-Net
Date: Tue, 10 Nov 1992 22:09:44 GMT


Hi, I have a struct te { int i; char c}
In the main part of the program I have the variable r declared
as type te.  I also have j as type char.  I then have
void *o   in there.  At first I have o point to j and do
a printf("%c",*(char *)o) and this works.  How would I use
o to point to r, and be able to print the c field?
Thanks...
 -Dan
-- 
    -Dan Newcombe
Internet Address:  STDN@VM.MARIST.EDU
Youngstown Freenet: ae007@yfn.ysu.edu
GOAL: To put the world on 3.5" diskettes...  :)
From: rab@sprite.berkeley.edu (Robert A. Bruce)
Newsgroups: comp.lang.c
Subject: C Users's Group Library on CD-ROM for $50
Date: 6 Nov 1992 10:34:37 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: jaywalk.berkeley.edu

The C Users' Group Library is now available on CD-ROM.  This is a collection
of user supported C source code from the C Users' Group.  Most of the code
is for MSDOS, but there are several volumes for Unix and other systems.
Some of the earlier volumes contain a lot of CP/M source code.  Volumes 100
to 364 are included on the disc.  There is source code for editors,
disassemblers, compilers, interpreters, communications, bbs's, games,
tutorials, math libraries, etc.  There are also all the source code listings
from "The C Users' Journal".  Part of the proceeds from this disc go to the
C Users' Group.  The price is $49.95.

The index files and readme.txt file for this disc are available via
anonymous ftp from cdrom.com(192.153.46.254):/pub/cdroms/cug, so you
can look at them before you decide if you want to buy it.

Shipping and handling is $5 (per order, not per disc) for US/Canada,
and $10 for airmail overseas ($15 for express airmail).  If you live in
California, please add sales tax.  You can send a check or money order to

    Walnut Creek CDROM
    1547 Palos Verdes, Suite 260
    Walnut Creek, CA  94596

Or you can order by MasterCard, Visa or American Express:

        +1 800 786-9907 US/Canada only
        +1 510 947-5996
        +1 510 947-1644 FAX
	email: rab@cdrom.com

If you would like a catalog of other CD-ROM titles available, you
can get it by anonymous ftp from cdrom.com:/pub/catalog.

	-bob

Newsgroups: comp.lang.c
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: cvs
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Wed, 11 Nov 92 19:53:06 GMT

In article 13515@cs.tcd.ie, dherity@cs.tcd.ie (Herity D.) writes:
>hamjavar@hydra.unm.edu (Farid Hamjavar) writes:
>>Has any one heard of this softeware called CVS  -- for managing
>>project source codes.  Do you know if it can be obtained free from
>>some archive (ftp).
>
>I'd like to know where to get it also.

CVS is distributed by the Free Software Foundation and will be available from
most sites that have GNU software (eg. prep.ai.mit.edu).

You will also need RCS (available from the same sites).

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: tsr's
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Distribution: comp
Date: Sat, 14 Nov 1992 03:23:25 GMT

corey.groves@canrem.com ("corey groves") writes:
: Hi,
:   I am trying to program a TSR and was wondering if anybody could point
:   me towards some good how to's on the subject.  I am running BC++ V3.1.
: Thanx
: Corey
: --

Good book would be: Memory resident programming on the IBM PC
                    by Thomas A. Wadlow
                    Addison-Wesley Publishing

you would also be smart to get one of the advanced MS-DOS books.

lastly, be prepared for some assembly code.

Dave Fuller
dfuller@portal.hq.videocart.com
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: a question on function returning a pointer to a function
Date: 12 Nov 92 21:07:24 GMT
Article-I.D.: thunder.1992Nov12.210724.5902
Distribution: usa
Organization: McGill Research Centre for Intelligent Machines

In article <1992Nov10.122953.17299@husc3.harvard.edu>, mlevin@husc8.harvard.edu (Michael Levin) writes:

> int a(int p);  int b(float p);

> int (*which_funct(s))() char *s;
> { [conditionally return(a) or return(b)] }

> cc (on a Sun) doesn't complain at all.  Neither does VAX-11 C.  gcc
> however gives an error about the last line (line 10) - incompatible
> types.

Because int (*)() (the return type) matches neither int (*)(int) (the
type of a) or int (*)(float) (the type of b).

It may be that gcc complains about b and not a because the argument
type doesn't match what would occur in the presence of default
promotions for an old-style argument list for b, but this isn't the
case for a.

> [W]hat if I want to return functions which take different arguments,
> like in the above example?

Cast them.  return((int (*)())a) and return((int (*)())b) should work
just fine.

Of course, you must cast the returned pointer back to the correct type
before actually calling through it.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.lang.c
From: books@fsunuc.physics.fsu.edu (Roger Books)
Subject: Re: GCC and all that
Organization: FSU nuclear physics
Date: Thu, 5 Nov 92 13:23:39 GMT

In article <alien.00qf@acheron.amigans.gen.nz> 
  alien@acheron.amigans.gen.nz (Ross Smith) writes:
>A few weeks ago I posted a request for information on how the GNU General
>Public Licence would affect software I wrote and compiled with GCC. Thanks
>to everyone who replied, especially Floyd Davidson, who did his level best
>to explain the Free Software Foundation to me...
>
>>
>>The general consensus among those who seem to know what they're talking
>>about, though, is that the latter is closer to the truth. Technically,
>>if I write my own source code, the resulting object code is mine too, and
>>the compiler writers have no say in the matter. In the real world, though,
>>a program that actually performs a useful function will always include
>>linked library code provided as part of the compiler package (yes, Floyd,
>>I know that's not strictly part of the *compiler* as such, but the
>>distinction is academic). This library code is, of course, covered by the
>>FSF's licence (the library licence is slightly different from the
>>application licence, but in this context the result is the same), and,
>>therefore, so is the resulting executable.
>

So what's the problem?  You tell your customer the program was written in
gcc and if they want copies of the tools used to build the application 
you will sell them a copy, including sources, for copying costs.

Roger
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: single formula for number of bits set in a byte
Date: 6 Nov 92 19:33:36 GMT
Organization: negligable

In article <6444@ucsbcsl.ucsb.edu> 6500msd@ucsbuxa.ucsb.edu (Michael D'Errico) writes:
>In article <530@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>
>]without divides, and relying on the `==` operator returning 1 or 0:
>
>]#define isset(x,bit)	((x & bit) == bit)
>]	count = isset(x,0x80) + isset(x,0x40) + isset(x,0x20) + isset(x,0x10) +
>]	        isset(x,0x08) + isset(x,0x04) + isset(x,0x02) + isset(x,0x01) ;
>
>It would be better to use
>#define isset(x,bit) ((x & bit) ? 1:0)

I have never met a compiler that yields other than 1 and 0 for
equality and relational expressions.

For C++ compilers this is guaranteed in the ARM (p74, section 5.9).
Unfortunately I don't have the ANSI C compiler document available
but I would suspect this is guarenteed there also.

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Moderation in all things....		         ....especially moderation.

Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: TRUE & FALSE
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Tue, 10 Nov 1992 21:42:54 GMT

 This is to clear up my response under "how's this for odd"

  I said I define TRUE and FALSE values. I meant that I have values that 
mean TRUE and FALSE (logically, not #defined). I do not redefine the
values of TRUE and FALSE.

I defined values like C_SUCCESS and C_FAILURE as return values for routines.

these are as return values only, and would never be used to test the result 
of a comparison or other c logic.

sorry about the confusion, my original response was not clear on this.

Dave Fuller
dfuller@portal.hq.videocart.com
From: ytsai@clyde.ICS.UCI.EDU
Subject: (none)
Newsgroups: comp.lang.c
Date: 9 Nov 92 20:37:13 GMT

Hi,

	I am using MSC V.6.0 to do some graphics.  Is there any way that I can
transfer an .exe file to a .com file? I tried using the exe2bin, but file cannot
be converted because my .exe file is created from .c file and there is a stack
segment.  I could not find an option in link which can make everything in just
one segment (CS, DS and SS are combined into one segment). As I am using the
graphics library, I am just afraid that my .exe file cannot be made into one
segment.
	I am grateful for any suggestions you may have.  Please send me mail
to:  ytsai@clyde.ics.uci.edu.  Thank you very much.

Youhua
From: Sepp@ppcger.ppc.sub.org (Josef Wolf)
Newsgroups: comp.lang.c
Subject: Re: Order of evaluation?
Distribution: world
Organization: PPC Germersheim, Germany
Date: 8 Nov 92 16:39:01 GMT

In <1992Nov6.125409.23455@unipalm.co.uk> tim@unipalm.co.uk (Tim Goodwin) writes:
] Josef Moellers <mollers.pad@sni.de> writes:
[ ... ]
] >	a() * b() * c() * e() * f() * g()
[ ... ]
] In the quoted example, each of the functions must be evaluated (although
] there is no guarantee about the order in which they are evaluated).  It
] is possible that the compiler might avoid some of the multiplications,
] if it happens to notice that they are unnecessary, but it may not omit
] any of the function calls.

Well, let's please go back to the original thread. Say: is the compiler
allowed to evaluate the expression given above in the following order:

a() * (b() * c()) * e() * f() * g() ?

Let's take a look at Section A7.6:

   A7.6 Multiplicative operators

     The multiplicative operators *, /, and % group left to right.
   [ ... ]

So the world seems to be OK. But look at Section A7:

   A7 Expressions

   [ ... ]
     The precedence and associativity of operands is fully specified, but
   the order of evaluation of expressions is, with certain exceptions,
       ^^^^^^^^^^^^^^^^^^^
   undefined, even if the subexpressions involve side effects. That is,
   unless the definition of an operator guarantees that its operands are
   evaluated in a particular order, the implementation is free to evaluate
   operands in any order, or even to interleave their evaluation. [ ... ]
        This rule revokes the previous freedom to reorder expressions with
        operators that are mathematically commutative and associative, but
        can fail to be computationally associative. [ ... ]

So the compiler seems to be allowed to evaluate

a * ( b * c )     instead of   a * b * c

but not

a * ( b / c )     instead of   a * b / c

Is this correct?

Greetings
    Sepp

-- 
|   Josef Wolf,  Germersheim,  Germany    aka    sepp@ppcger.ppc.sub.org   |
|    also available via    ..!uunet.uu.net!ira.uka.de!smurf!ppcger!sepp    |
|--------------------------------------------------------------------------|
| ...und wieviel brave Deutsche haben wieder nichts geschnallt... (Marius) |
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Hows this for odd
Date: 11 Nov 92 12:33:13 GMT
Organization: University of Helsinki

I a recent article I wrote:
>A bit like most people seem to always use printf to print
>to stderr, instead of putchar, puts, or some other function, 
    ^^^^^^

This should be stdout, of course.  

(Going to four different movies in a row seems to affect one's ability
to get details correct.)

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Xref: sparky comp.lang.c:16304 comp.lang.c++:16064 comp.lang.pascal:6472 comp.lang.misc:3578
From: mbrown@testsys.austin.ibm.com (Mark Brown)
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.pascal,comp.lang.misc
Subject: Re: Godel's Proof (was Re: Software design =/= Programming)
Date: 10 Nov 92 19:34:49 GMT
Organization: IBM Corp., Austin TX.

| loegel@sscvx1.ssc.gov writes:
|From the McGraw-Hill Dictionary of Science and Technology:
|Godel's Proof: Any formal arithmetical system is incomplete in the
|
|The full proof *is* wonderful -- we took six weeks going through it in
|class. Also, Raymond Smullyan has just published a book (Oxford Press)
|where he gives *three* different proofs of the Incompleteness Theorem.
|Smullyan is a wonderful author (e.g. "Forever Undecided : a puzzle
|guide to Godel" and "To Mock a Mockingbird") and I recommend any of
|the books. 

Shame on you for not recommending GODEL, ESCHER, BACH: An Eternal Golden
Braid, by Douglas Hofstadter.

Not only a good explanation of Godel, but he ties it back into
programming and AI.

mark
-- 
Mark Brown       IBM PSP Austin, TX.|Make it right before you make it faster.
(512) 838-3926   VNET: MBROWN@AUSVMQ|Keep it right when you make it faster.
MAIL: mbrown@testsys.austin.ibm.com |Make it clear before you make it faster.
DISCLAIMER: My views may be, and often are, independent of IBM official policy.
From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Order of evaluation
Date: 9 Nov 92 18:11:20 GMT
Reply-To: volpe@ausable.crd.ge.com
Organization: GE Corporate Research & Development

In article <1992Nov9.065342.20862@dartvax.dartmouth.edu>, davidg@polvadera.dartmouth.edu (David Gelhar) writes:
|> In article <qBak-G@ppcger.ppc.sub.org>  writes:
|> > 
|> > So the compiler seems to be allowed to evaluate
|> > 
|> > a * ( b * c )     instead of   a * b * c
|> > 
|> > but not
|> > 
|> > a * ( b / c )     instead of   a * b / c
|> > 
|> > Is this correct?
|> > 
|> 
|> No. The point to remember is that precedence/associativity are NOT the

This is all correct...

|> same thing as order of evaluation.  The expression "a * b * c" is required
|> to be treated like "(a * b) * c", that is, "a" and "b" are multiplied together
|> and the result is multiplied by "c"; that's the associativity rule.  As it
|> says above, "the precedence and associativity of operands is fully specified".
|> In other words, the parsing of the expression (what operands go with what
|> operators) is precisely defined:  the operands of the rightmost "*" in this
|> example are "a*b" and "c".  What's undefined is the order of evaluation -- 
                                      ^^^^^^^^^ unspecified

|> the subexpressions "a", "b" and "c" are not required to be evaluated in any
|> particular order.
|> 
|> The only time order of evaluation matters (indeed, the only time you can
|> even _tell_ what order is being used, without resorting to looking at
|> object code) is when the subexpressions have side effects.  For example,
|> in "a() * b() * c()" there's no telling what order the functions may be
|> called in.  This is fine if the functions have no side effects, but if
|> they do (for example, if they print the function name on the terminal
|> when called) the results are undefined.

No, the results are not undefined. The result is that the function names
must be printed out in some order, not necessarily even documented by the
compiler writer. But they must be printed out. The computer is not allowed
to turn into a frog at runtime.

-Chris
-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
Newsgroups: comp.lang.c
From: dan@BofA.com (Dan Brockman)
Subject: Re: Godel's Proof (was Re: Software design =/= Programming)
Organization: Bank of America, Capital Products, RMTG #5906
Date: Fri, 13 Nov 92 05:21:53 GMT

Newsgroups: comp.lang.c
Subject: Re: Godel's Proof (was Re: Software design =/= Programming)
Summary: 
Expires: 
Followup-To: 
Distribution: 
Organization: Bank of America, Capital Products, RMTG #5906
Keywords: 




In article <4002@eastman.UUCP> vec@alnitak.Kodak.COM (Vance Cochrane) writes:
>In article <BxHz2v.EK4@sci.kun.nl>, hansm@cs.kun.nl (Hans Mulder) writes:
>>In <LOEGEL.92Nov9134531@fegatello.ssc.gov> loegel@fegatello.ssc.gov (George J. Loegel) writes:
>>>From the McGraw-Hill Dictionary of Science and Technology:
>>>Godel's Proof: Any formal arithmetical system is incomplete in the
>>>sense that, given any consistent set of arithmetical axioms, there are
>>>true statements in the resulting arithmetical system that cannot be
>>>derived from these axioms.
>
>WHAT DOES THIS HAVE TO DO WITH THE C PROGRAMMING LANGUAGE !!!!!
>ANSWER:
>NOTHING.

I have wondered whether there was not a fundamental problem of 
Godelian sort in C++ by treating everything as an object, though
I've not been able to articulate my concern clearly.  Something
along the lines of C++ requiring an endless supply of keywords
or infinitely many objects or maybe I am not thinking clearly
about this or ...


-- 
 --------------------------------------------------------------
 Daniel Brockman             tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA    email uunet!odinba!dan dan@BofA.COM
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: void pointer to a struct?
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Wed, 11 Nov 1992 23:18:33 GMT

ae007@yfn.ysu.edu (Daniel Newcombe) writes:
: 
: Hi, I have a struct te { int i; char c}
: In the main part of the program I have the variable r declared
: as type te.  I also have j as type char.  I then have
: void *o   in there.  At first I have o point to j and do
: a printf("%c",*(char *)o) and this works.  How would I use
: o to point to r, and be able to print the c field?
: Thanks...
:  -Dan

---------------------

If r is type te then
printf("%c", r.c);
works rather well.

---------------------

if you want to pass r around then use the pointer to it elsewhere do

o = (void *) &r;

to print out the char element c do

printf("%c", ((struct te*)o)->c);

---------------------
pretty messy, huh ?

this could be done MUCH cleaner using another method. But using the types
and methods that you defined, this works for it.

Dave Fuller
dfuller@portal.hq.videocart.com

Xref: sparky comp.lang.c:16059 comp.lang.c++:15852 comp.lang.pascal:6368 comp.lang.misc:3514