HDTenEightyP/NetNews huggingface dataset:
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Help!! with flex/byacc on Borland C
Date: Tue, 06 Oct 1992 21:39:27 GMT
Organization: Security APL, Inc.

In article <GUENTHER.92Oct6131444@snookles.stolaf.edu> guenther@stolaf.edu (Philip Guenther) writes:
>In <s912121.718333321@minyos.xx.rmit.OZ.AU> s912121@minyos.xx.rmit.oz.au (Joydip Das) said:
>   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?

Unfortunately, __STDC__ is supposed to mean absolutely standard ANSI C, no
extensions not allowed by the standard.  But there are conventional
extensions on PC C compilers (the "near" and "far" keywords, etc.) which
violate this aspect of the standard.  So __STDC__ is not, by default,
defined on PC's.  However, most PC compilers today are "essentially" ANSI
compilers, not K&R compilers, and in particular expect prototypes.

Thus being sneaky meets its usual reward in this business.

In practice, as a first cut, the ANSI C flag can be specified on the
compiler (I know Borland has one).  For later development, you may want to
use the special PC stuff; if so, you should manually change the prototype
stuff.  Alternatively, you may want to use the gcc compiler itself for later
development, once you get it running.
From: kovach@kahane.cogsci.uiuc.edu (Edward Kovach)
Newsgroups: comp.lang.c
Subject: 32 bit c/c++ compiler for ps/2
Keywords: compiler c/c++ ps/2
Date: 30 Sep 92 15:48:49 GMT
Article-I.D.: kahane.kovach.717868129
Organization: University of Illinois at Urbana

Hi,

I have a friend who is looking for a 32 bit c/c++ compiler for 
his ps/2.  We're heard there is a shareware version available.

Does anyone have any information on it and where it can be ftp'ed from?

Ed Kovach - kovach@kahane.cogsci.uiuc.edu
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Strings and integer sizes
Organization: SoftQuad Inc., Toronto, Canada
Date: Sun, 4 Oct 92 11:22:50 GMT

> > > The ANSI Standard for C guarantees that
> > >	sizeof(short) <= sizeof(int) <= sizeof(long)
> > True.
> I was just browsing through the Standard earlier today, and 
> interestingly enough, it doesn't explicitly state this anywhere.  

Right.

> What it does state is that the values taken by a short are
> a (possibly non-proper) subset of the values taken by an int
> which are a (possibly non-proper) subset of the values taken
> by a long ...  Presumably a 'short' could occupy more
> bits than an 'int', with many bit patterns defining the same value
> or being undefined.  I'm not claiming that this is a reasonable
> thing to do, only that I don't see it explicitly forbidden by
> the Standard.

That's explicitly forbidden in section 3.1.2.5 (ANSI numbering, 6.1.2.5
in ISO version), where it requires integer types to use a pure binary
representation.  (The actual wording allows things like 2's complement
-- actually it *doesn't*, but a footnote, which belongs in the main text,
corrects this.)  This, together with the requirement on representable
values, implies the requirement on sizes.
-- 
Mark Brader		"'Settlor', (i) in relation to a testamentary trust,
Toronto			 means the individual referred to in paragraph (i)."
utzoo!sq!msb, msb@sq.com		-- Income Tax Act of Canada, 108(1)(h)

This article is in the public domain.
Newsgroups: comp.lang.c,comp.lang.c++,comp.os.msdos.programmer
From: mustafa@seas.smu.edu (Mustafa Kocaturk)
Subject: Re: [Stack Overflow] How do I find cause using Turbo Debugger?
Organization: SMU School Of Engineering and Applied Science
Date: Fri, 2 Oct 1992 19:46:15 GMT

In article <1992Oct2.111836.24936@gdr.bath.ac.uk> ccsmh@gdr.bath.ac.uk (Mark Harding) writes:
>My program recently bombed out with a 'Stack Overflow!' message on the screen.
>I have stopped it doing so by increasing _stklen but I'd really like to
>find the point in my program that caused the overflow in the first place.

Check functions that use a lot of stack space, such as those
having large automatic arrays and/or calling themselves
recursively and indefinitely. I would rather avoid resorting to the debugger,
in favor of adding my own debugging messages into the program if possible.
-- 
Mustafa KOCATURK  mustafa@seas.smu.edu   Electrical Engineering Department
Home:(214)706-5954  Work:(214)692-2541   SMU Box 753190, Dallas, TX 75275-3190
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Curses to write to stderr, possible?
Date: 1 Oct 92 22:59:42 GMT
Organization: negligable

If you can isolate the curses stuff in subroutines you could
always play games w/ the file pointers....


	displaySomething(...)
	{
	FILE *old = stdout;
	stdout = stderr;

	....

	stdout = old;
	}

(very important to restore stdout when you get done!)

		-Richard Hartman
		hartman@uLogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Disco isn't dead...			...it's just in witness protection!

Newsgroups: comp.lang.c
From: gregh@alw.nih.gov (Gregory Humphreys)
Subject: Re: unpredictable post-decrement behavior.
Organization: National Inst. of Health, DCRT, CSL
Date: Fri, 2 Oct 1992 12:10:45 GMT

In article <1992Oct2.114217.384@rz.uni-karlsruhe.de>, "hans friedrich steffani" <GM08@DKAUNI2.BITNET> writes:
|> 
|> 
|> > >>herzog@ux5.lbl.gov (Hanan M. Herzog) writes:
|> > >>:              product *= (double)(4 * n * n) / ((4 * n * n++) - 1);
|> > >>: Some compilers had no problem with this line at all. However some
|> > >>: hurled completely upon sight of the 'n++'. A few compilers required
|> > >>: me to place the 'n++' on the next line in the while loop. So
|> > >>: the code looked like:
|> > >>:              product *= (double)(4 * n * n) / ((4 * n * n) - 1);
|> > >>:              n++;
|> > >>: Why did some compilers get and others not?
|> 
|> i think ppl who wrote code like this should be fired. this is no
|> defensive prgramming, difficulty to understand an perhaps in the
|> result compilerdependet. so dont use constructs like this.
|> 
|> hans friedrich steffani
|> uni-karlsruhe
|> gm08@dkauni2.bitnet
|> steffani@imbaibrs1.bau-verm.uni-karlsruhe.de

Well, Hans, I'm glad you are the authority on aesthetic C constructs.
Personally, as I program C every day at my job, I use constructs like the
above all the time.  I find them much easier to use and understand.  One of 
the beauties of C is it's compactness, and writing code with the n++ on the
next line sort of defeats the purpose.  Of course, there is the problem of
some compilers not recognizing that construct, but if your compiler doesn't, you're either using a C-64 or it's time to get a new compiler.

-- 
Greg Humphreys    |  "Playing not to win is like sleeping with your 
gregh@alw.nih.gov |  sister - sure, she's a great piece of tail, 
                  |  and she's got a bag full of goodies, but it's 
(301) 402-1817    |  just plain illegal."  -Charlie Sheen, "Hotshots"
From: eychaner@suncub.bbso.caltech.edu (Another casualty of applied metaphysics)
Newsgroups: comp.lang.c
Subject: Re: Determining variable type at run-time (followup q.)
Date: 3 Oct 1992 06:36:54 GMT
Organization: Big Bear Solar Observatory, Caltech
Reply-To: eychaner@suncub.bbso.caltech.edu
NNTP-Posting-Host: suncub.bbso.caltech.edu

hartman@ulogic.UUCP (Richard M. Hartman) writes:
>berlin@is.morgan.com (Alexander Berlin) writes:
>>hartman@ulogic.UUCP (Richard M. Hartman) writes:
>>
>>>Safer would be:
>>>
>>>		x.value = malloc(strlen(str));
>>>		strcpy(x.value, str);
>>>
>>Doesn't look very safe to me.
>
>Sorry.  Third most common error in C.
>
>	x.value = malloc(strlen(str)+1);
>	strcpy(x.value, str);

Shouldn't there be a check for malloc() failure between those statements as
well?  (In fact, when I saw Alexander's post, I assumed that THAT was what
he was referring to!)  Like:

>	x.value = malloc(strlen(str)+1);
	if (!x.value) /* print some error message and exit */ ;
>	strcpy(x.value, str);

-G.
******************************************************************************
Glenn Eychaner, Big Bear Solar Observatory, California Institute of Technology
NSI/DECnet: SUNCUB::EYCHANER        Internet: eychaner@suncub.bbso.caltech.edu
USmail: 40386 North Shore Lane                eychaner_g@caltech.edu
        Big Bear City, CA  92314    Phone: (714) 866-5791 or (818) 356-4014
                                           (909) after November 14, 1992
"I don't do Windows."
"Even the hardest concrete never quite sets.  And the sun never sweats."
Newsgroups: comp.lang.c
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Subject: Probably a simple realloc() question
Organization: Department of Philosophy, University of Utrecht, The Netherlands
Date: Mon, 28 Sep 1992 00:29:59 GMT


Probably a simple question for some of you...
Suppose I've got the following piece of code:

    #define MaxNoOfThings 1024L*256L

    typedef struct {
                 ...
    } THING;

    THING ManyThings[MaxNoOfThings];

    int init_things( void )
    {
       int i=0;
       
       for( ; i<MaxNoOfThings; i++ )
          if( fill_things(ManyThings[i]) ) break;
       return i;
    }

The function that calls init_things() now knows how many THINGs have been
filled (i). It is possible that not all THINGs have been filled, so a
large part of the array ManyThings is unused. I now want to free this 
unused memory. What's the best way to do this?
I could malloc space for MaxNoOfThings*sizeof(THING), and declare
ManyThings as a THING * , instead of declaring it as an array. I could
then realloc(ManyThings, (i+1)*sizeof(THING)).
Of course this is the obvious way to go (I think), but:
is it the best/only solution? Are there other solutions that don't run
the risk that reallocation fails (so preferably a solution that doesn't 
use realloc at all :-)? I just don't want to waste large amounts of
memory...

Couldn't find it in the FAQ...

Thanks in advance for any reply (excluding flames),
Hendrik Jan

--
Hendrik Jan Veenstra                            hjv@phil.ruu.nl
Department of Philosophy              -------------------------------------
University of Utrecht                     All opinions expressed above
The Netherlands                               are pure coincidence 
Newsgroups: comp.lang.c,news.answers
From: steve@taumet.com (Steve Clamage)
Subject: Re: Probably a simple realloc() question
Organization: TauMetric Corporation
Date: Tue, 29 Sep 1992 16:19:45 GMT

hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:

>karl@ima.isc.com (Karl Heuer) writes:

>>$ If realloc() fails when you try to *shrink* a buffer, you should complain
>>  to your vendor.  (It's not a violation of the Standard, but it's definitely
>>  poor quality.)

>That depends IMO. If realloc first mallocs a block of size newsize and then
>frees the oldsize block, it could be that there is no room to malloc newsize
>while oldsize is still occupied. I must say that it didn't actually go wrong,
>but I was just wondering... always anxious to learn...

To repeat what Karl said, it is not a violation of the Standard, but
it is definitely poor quality.  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.

"Quality" implies producing good results efficiently.  An implementation
might produce poor results and waste time and resources, but not violate
any provision of the Standard.  That doesn't mean it is good quality.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: can != be used in compound if
Date: 1 Oct 92 06:28:51 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <30SEP199207384410@accvio.intel.com>, dmills@accvio.intel.com (Dave Mills) writes:
> I think the problem here is operator precendence.  If my memory serves me,
> without K&R in hand, && has higher precendence than !=.

Wrong.  Like almost every computer programming language _except_ Pascal,
C's || and && have wider scope than C's comparison operators.

> Add a few parens, like this:
> 	if ((rnum != number_set[1]) && (rnum != number_set[2]) &&
> 		(rnum != number_set[3]))
> and it should work okay.

I personally find the statement much easier to read without a rash of
superfluous parentheses, but it won't do any harm to add them if you
have to work with people who aren't sure about C syntax.

For people who _are_ confused about C operator precedence there is a useful
program available from a sources archive near you:  cparen.

When I fed
 if (rnum != number_set[1]
  && rnum != number_set[2]
  && rnum != number_set[3]) x;
to cparen's standard input I got

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

back.  Two other useful free programs for C programmers are
	cdecl	- explain and generate C declarations and casts
	indent	- reformat a C program to be less unreadable

Without knowing what rnum and number_set[] are, or what the statement
is _supposed_ to do and how it misbehaves, this is all the help I can give.
-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
Newsgroups: comp.lang.c
From: abutler@ariel.demon.co.uk (Tony Butler)
Subject: C Database
Distribution: world
Organization: Megadodo, Inc.
Date: Sun, 27 Sep 1992 14:02:12 +0000

Hi,

I'm trying to write a database application in C, and I want the records
to be in alphabetic order. The 'obvious' solution is to use a doubly
linked list to maintain this order. The problem is though that I
anticipate having a database too big to fit in memory, so I can't load
it all up, search the database, and add a new record in the appropriate
place. So the problem is, how do I search this database and add records
to it - with a linked list, the links point to memory locations, which
is no good if the records are on disk. Aslo, I would (presumably) want
to maintain a buffer of x records in memory top speed things up a bit -
what's the best way to go about this??

Any help would be much appreciated, please email your response.


   Tony.


 ----------------------------------------------------------------------------
| Tony Butler                           Internet: abutler@ariel.demon.co.uk  |
| Surrey,                                 TCP/IP: 158.152.8.125              |
| England.                               Fidonet: Anthony Butler @ 2:250/408 |
 ----------------------------------------------------------------------------

Xref: sparky comp.lang.c:14207 comp.lang.c++:14243 comp.unix.admin:5257 comp.unix.sysv386:15022 comp.unix.programmer:4806 comp.unix.shell:4148 comp.unix.wizards:4096
From: pickens@bsu-cs.bsu.edu (David B. Pickens)
Newsgroups: comp.lang.c,comp.lang.c++,comp.unix.admin,comp.unix.sysv386,comp.unix.programmer,comp.unix.shell,bsu.unix,comp.unix.wizards
Subject: Need a formatter for C programs
Date: 28 Sep 92 19:22:27 GMT
Organization: Dept. of CS Ball State University Muncie IN

I have inherited a project written in C and it is in dire need of
being formatted in K&R or some other easy to read style.  I tried
to use cb - c beautifier on my unix machines, but it only does
indentation.

I am looking for either a program written in ANSI C or a shell
script for UNIX V.  Any other ideas welcomed.

Please e-mail me so bandwidth is not wasted.  I'll post a follow-up
as to what worked.

David


Newsgroups: comp.lang.c,comp.lang.c++,comp.unix.admin,comp.unix.sysv386,comp.unix.programmer,comp.unix.shell,bsu.unix,comp.unix.wizards,comp.unix.misc
Subject: Need a formatter for C programs
Summary: 
Expires: 
Followup-To: 
Distribution: 
Organization: Dept. of CS Ball State University Muncie IN
Keywords: 

I have inherited a project written in C and it is in dire need of
being formatted in K&R or some other easy to read style.  I tried
to use cb - c beautifier on my unix machines, but it only does
indentation.

I am looking for either a program written in ANSI C or a shell
script for UNIX V.  Any other ideas welcomed.

Please e-mail me so bandwidth is not wasted.  I'll post a follow-up
as to what worked.

David


-- 
David B. Pickens | pickens@bsu-cs.bsu.edu 
Grad. Student & Grad. Assistant | Center for Information and
                                  Communication Sciences
"Ouch!" - Newton's first words after discovering gravity
Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Is there is (pascal) WITH equivalent in C?
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 1 Oct 1992 15:04:26 GMT

ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke) writes:

>jos@and.nl (Jos Horsmeier) writes:
>> 
>> ... 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.

If you're interested in efficiency, then don't use a non-optimising compiler!
Efficiency arguments that only apply if you have a brain-dead compiler
leave me completely unconvinced.

-- 
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!
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: sprintf
Date: 1 Oct 92 21:57:11 GMT
Organization: University of Helsinki

rehak@breeze.rap.ucar.edu (Nancy Rehak) writes:
>There are no side effects associated with such usage except the usual concerns
>(making sure s1 is large enough, etc.).  

and making sure that s2 doesn't contain a percent character, etc.

>However, it is probably more efficient to use strcpy or strncpy to copy
>strings. 

A lot clearer too for many people.

--
Lars.Wirzenius@helsinki.fi
From: pjh@mccc.edu (Pete Holsberg)
Newsgroups: comp.lang.c
Subject: Re: Lint Puzzler
Date: 6 Oct 92 00:44:21 GMT
Organization: The College On The Other Side Of Route One

In article <1992Sep27.174230.18587@ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:
=Sometimes the non-Standard and Standard versions of the header are combined
=into a single file with the sections delimited by #if directives.  For
=example, it might be that you can force your <stdio.h> to be conforming by
=simply using   #define _ANSI_SOURCE   *before* you include the header.  You'll
=have to look at the header to see what symbol, if any, controls this behavior.
=
=Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint

I decided to remove and reinstall, and now everything is once again OK.
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: unpredictable post-decrement behavior.
Organization: Sequoia Peripherals, Inc.
Date: Fri, 2 Oct 92 16:17:18 GMT

In article <1992Oct2.121045.24203@alw.nih.gov> gregh@alw.nih.gov (Gregory Humphreys) writes:
>|> > >>:              product *= (double)(4 * n * n) / ((4 * n * n++) - 1);
>|> 
>|> i think ppl who wrote code like this should be fired. this is no
>|> defensive prgramming, difficulty to understand an perhaps in the
>|> result compilerdependet. so dont use constructs like this.
>
>Well, Hans, I'm glad you are the authority on aesthetic C constructs.
>Personally, as I program C every day at my job, I use constructs like the
>above all the time.  I find them much easier to use and understand.  One of 
>the beauties of C is it's compactness, and writing code with the n++ on the
>next line sort of defeats the purpose.  

Thanks for warning us about how you do your job. Now none of us
have to worry about hiring you.

While I care very much about C stylistic concerns, I recognize 
that many of the questions raised are judgment calls. But I have
to wonder about a programmer who insists on using constructs
that are not legal C just because he finds them easier to use
and understand. And then blaming the compiler if it gets it "wrong".



-- 
Dave Eisen    dkeisen@leland.Stanford.EDU   Sequoia Peripherals: (415) 967-5644
      There's something in my library to offend everybody.
        --- Washington Coalition Against Censorship
Newsgroups: comp.lang.c
From: bibhas@pico.engr.mun.ca (Bibhas Bhattacharya)
Subject: Calling FORTRAN from C; Losing sleep.
Keywords: FORTRAN
Organization: Memorial University of Newfoundland
Date: Sat, 3 Oct 1992 22:23:28 GMT


Hi,
I am working on ULTRIX platform and I want to call FORTRAN subroutines from C.
I figured out FORTRAN always passes arguements to a function by reference (by address that is). I wrote a small fortran function and made a .o file and finally a library which I linked to my C program. My cc gave a 'function undefined' error. Here are the programs. I need urgent help to solve a major problem.

******C code*****

#include<stdio.h>
main(int argc, char *argv[]){
	int sm, a1, a2;
	a1 = atoi(argv[1]);
	a2 = atoi(argv[2]);
	sum(&a1, &a2, &sm);
	printf("%d + %d = %d\n", a1, a2, sm);
}


*****FORTRAN code****

c	nice program
	call sum(A1, A2, S)
	stop
	end
	subroutine sum(A1, A2, S)
	S = A1 + A2
	return
	end
Xref: sparky comp.lang.c:14572 comp.lang.c++:14573