HDTenEightyP/NetNews huggingface dataset:
From: scott@mcl.ucsb.edu (Scott Bronson)
Newsgroups: comp.lang.c
Subject: Re: Is there is (pascal) WITH equivalent in C?
Date: 6 Oct 92 20:15:47 GMT

In <20992@plains.NoDak.edu> heilig@plains.NoDak.edu (Zachary Heilig) writes:

>try:
>	a.next := a.next^.next;
>	a.next^.next^.prev := a;
>	      ^^who the hell thought up the ^. awkward operator anyway?

Niklaus Wirth, who do you think?  I like Pascal's "^." pointer indirection
much better than C's "(*a).next".  The "->" is only a shortcut as you will
quckly find when you attempt double-indirection.

[long answer to a question not asked deleted.]

	- Scott
Newsgroups: comp.lang.c
From: rjf@dptg.att.com (51351[efw]-Robert Feddeler(MT4799)T343)
Subject: Re: unpredictable post-decrement behavior.
Organization: AT&T/NCR, Lincroft, NJ, USA
Date: Mon, 5 Oct 1992 17:30:25 GMT

In article <1992Oct2.174215.10569@CSD-NewsHost.Stanford.EDU> amorgan@Xenon.Stanford.EDU (Crunchy Frog) writes:
>In article <1992Oct2.121045.24203@alw.nih.gov> 
>  gregh@alw.nih.gov (Gregory Humphreys) writes:
>>
>>Well, Hans, I'm glad you are the authority on aesthetic C constructs.
>
>Aesthetics has nothing to do with it.
>
>>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.
>
>For the 100th time.
>
>a = n * n++;
>
>is *wrong*.  It is not easier to understand.  It is not compact.  It is
>invalid.  If you use this construct you *should* be shot.
>

C Frog is right.  Consistency, doing the same thing the same way all of
the time, is a characteristic of the most readable programs.  Arbitrary use
of ++ and += to increment is distracting.  I always use += because the
same construct will work for all increments, not just "1".  It always
goes on a separate line because it is probably important for the reader
to know it's there.

Maybe I think too much like a PDP-11, but the only place I'll use ++
is in an array index.  Very concise, very readable, (and consistent).

Now for the controversy:

IMHO, the reason the compiler assigns different precedence to different
arithmetic and logical operators is because 1) it is so easy to
do and 2) straight left-to-right would be silly.  But don't be too quick
to say "Thank you".  This is almost never good for you.  All compound
expressions _must_ be fully parenthesised.  When the unfortunate reader
is looking for a bug, don't distract her primary train of thought by
having to test each expression for correct implicit order-of-evaluation.

Anyway, most of us can type "(a * b) + c" faster than we can "know" that
"a * b + c" will work.  Yes, the former looks better too and no, I don't
want to argue about which one looks better... Just do it!


brer bob.		| Heap big trouble in the land of plenty.
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 28 Sep 92 18:11:27 GMT
Article-I.D.: ima.1992Sep28.181127.25818
Organization: Formerly of Interactive Systems, Cambridge, MA

[Note: I've commented on a few side issues via footnotes.  --kwzh]

In article <hjv.717640199@groucho.phil.ruu.nl> hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
>[Code using a huge array, but it may turn out that not all of it is needed]
>I now want to free this unused memory.  I could malloc space for
>Max*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 [$]?  I just don't want to waste large amounts of memory...

The alternative is not to allocate so much memory in the first place.  (This
is generally a better solution, partly because many implementations will not
return the unused space to the operating system, although it is held available
for future malloc() requests within the same program.)  I am enclosing three
ways to do that.  I left out the error-checking.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
________
% Do you really mean i+1?  It looks to me as though the loop always halts
  with i elements having been filled (subscripts 0 through i-1), so you
  should realloc to i*sizeof(THING).
$ 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.)

/* #1: Find some way to count them in advance */
int init_things(void) {
    int i, count;
    count = figure_out_how_many_things();
    ManyThings = malloc(count * sizeof(THING));
    for (i = 0; i < count; ++i) fill_things(ManyThings[i]);
    return (count);
}

/* #2: start small, and grow as needed */
/* The final realloc() can be omitted if you're paranoid about */
/* it failing; the amount of wasted space is limited. */
int init_things(void) {
    int i = 0, size = SOME_RANDOM_GUESS;
    ManyThings = malloc(size * sizeof(THING));
    do {
	if (i >= size) {
	    size = 2*size;
	    ManyThings = realloc(ManyThings, size * sizeof(THING));
	}
    } while (!fill_things(ManyThings[i++]));
    ManyThings = realloc(ManyThings, --i * sizeof(THING));
    return (i);
}

/* #3: use a linked list (or some other data structure) */
typedef struct THING THING;
struct THING { ... THING *next; };
int init_things(void) {
    int count = 0;
    THING **ptail = &ManyThings;
    for (;;) {
	*ptail = malloc(sizeof(THING));
	if (fill_things(*ptail)) break;
	ptail = &(*ptail)->next;
	++count;
    }
    free(*ptail);
    *ptail = NULL;
    return (count);
}
From: ski@atc.boeing.com (Chris Kacoroski,none)
Newsgroups: comp.lang.c
Subject: Need small forward-chaining inference engine
Date: 1 Oct 92 13:38:07 GMT
Reply-To: ski@atc.boeing.com
Organization: Boeing - Product Manufacturing Knowledge Based Systems

Hi,

My group needs the C or C++ code for a small, simple forward chaining 
inference engine.  We want to create a fact/rule file that the engine
reads and then have it operate over a data set.  Please reply directly
to me because I do not normally read this group.  Thanks.


Cheers,

Chris "ski" Kacoroski	"When we try to pick out anything by itself
ski@atc.boeing.com	 we find it connected to the entire universe"
							John Muir
From: scotth@felix.filenet.com (Scott Hopson)
Newsgroups: comp.lang.c
Subject: Re: line number in C program
Date: 7 Oct 92 02:25:25 GMT
Reply-To: scotth@fritz.filenet.com (Scott Hopson)
Organization: FileNet Corp., Costa Mesa, CA

In article <1992Oct5.193542.11024@cs.brown.edu> 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?
>

If using Borland C or C++ you can try __LINE__






-- 
Scott Hopson   (scotth@filenet.com)
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: SUMMARY:  Preferences toward case sensitivity/insensitivity
Date: 28 Sep 92 05:46:59 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <729@mtinews.mti.com>, adrian@mti.mti.com (Adrian McCarthy) writes:
> And portability is one of the omitted arguments for case-insensitivity.
> There are environments in which the linker is case-blind, so a case-sensitive
> language has to make exceptions for external identifiers on those platforms.

If you want to take the deficiencies of vintage linkers as a basis for
language design, you had beterr restrict yourself to at most 5 characters
consisting of digits and upper case letters only.  (If all the IBM 1130s
out there are dead or in museums, you _might_ be able to get away with 6.)

In fact there is no reason why a linker should be allowed to cripple any
language.  It is always possible for a compiling system to manage its own
name space on top of the linker's.  Eiffel, C++, and Ada already have to do
this because in one form or another they allow overloading, so there may be
several globally visible things with the same identifier (as long as the
rest of the signature is different).
-- 
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,gnu.gcc.help,comp.sys.sun.misc
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Subject: Re: gen complete set of prototypes
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Wed, 30 Sep 92 23:52:30 GMT

In article <1992Sep30.201825.2164@eng.ufl.edu> ruck@zeta.ee.ufl.edu (John R Ruckstuhl Jr) writes:
>I want to code in ANSI C, and compile with "gcc" with lots of strict
>checking.
>
>If I understand this right, the installation of gcc derives ANSI
>function prototypes from the native include files and generates the ANSI
>compatible include files.

Nope, fix-includes strives only to remove outright errors, and even then,
not very well.

>But for my system (SunOS 4.1.1) the original include files don't declare
>all functions -- many, especially those returning int, aren't there.
>So the derived header files are likewise incomplete.
>
>Which means the user has to write some of his own prototypes.
>
>If one writes the prototype for a library function wrong, and uses the
>function consistantly wrong, no compiler checking is going to catch it.

You could start with the lint library sources.  Look in /usr/lib/lint.

>and, more generally,
>wouldn't they be easy to generate from source with some utility
>(cproto?) ?  There are some persons on my campus licensed to play with
>the Sun sourcecode.

Now there's a thought.  Why not use protoize, which comes with gcc-2.x
and protoize all the sources, strip out the code, figure out how and
where to merge the function prototypes into the headers, 'diff -c' the
new headers against the old, and send the diffs to the Free Software
Foundation, and then hire a lawyer to defend you when Sun files a copy-
right violation lawsuit against you.  :-)

>How do you handle this issue?

When I do "pedantic linting" with gcc, I still make the final determination 
as to whether a gcc detected error is really an error...

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.
Newsgroups: comp.lang.c
From: ortiz@susan.cs.andrews.edu (Victor Ortiz)
Subject: SCREEN HANDLING LIBRARIES?
Organization: Andrews University
Date: Tue, 6 Oct 1992 21:49:38 GMT

Does anybody know of any good c shareware libraries that helps in screen design
and data entry?  If you do please e-mail me directly.

Thanx, Victor Ortiz

e-mail: ortiz@susan.cs.andrews.edu
From: alsaggaf@athena.mit.edu (M. Saggaf)
Newsgroups: comp.lang.c
Subject: Curses to write to stderr, possible?
Date: 30 Sep 92 22:43:14 GMT
Article-I.D.: athena.1992Sep30.224314.17911
Organization: Massachusetts Institute of Technology

I have a need to write a program that uses curses to write to stderr
(since stdout is redirected to a device). Is that possible? if so, how
is that done? Please help. I'll later summarize.

                                        -- M. saggaf
                                          alsaggaf@athena.mit.edu



--
/M. Saggaf
 alsaggaf@athena.mit.edu
Newsgroups: comp.lang.c
From: hollasch@kpc.com (Steve Hollasch)
Subject: Re: ++i = i++ ?
Summary: This is NOT a valid statement, BTW.
Organization: Kubota Pacific Computer, Inc.
Date: Mon, 28 Sep 1992 21:17:59 GMT

zxmgn01@mailserv.zdv.uni-tuebingen.de (Philipp Knirsch) writes:
|
| ++i = i++;
| 
| Hehehe.. Which value has i when it is first 0 after this line of correct 
| C-Code??
| 
| Normaly first the left part is calculated, so this is in our case 0.
|
| [ remainder deleted ]

    No, "++i = i++;" is not a valid statement in C.  It's an assignment
statement with an invalid left-hand side.

______________________________________________________________________________
Steve Hollasch                                   Kubota Pacific Computer, Inc.
hollasch@kpc.com                                 Santa Clara, California
Xref: sparky comp.lang.c:14494 comp.lang.c++:14478 comp.os.msdos.programmer:9714
From: scotth@felix.filenet.com (Scott Hopson)
Newsgroups: comp.lang.c,comp.lang.c++,comp.os.msdos.programmer
Subject: Re: [Stack Overflow] How do I find cause using Turbo Debugger?
Date: 3 Oct 92 09:28:04 GMT
Reply-To: scotth@fritz.filenet.com (Scott Hopson)
Organization: FileNet Corp., Costa Mesa, CA

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.
>
>Can this be done easily? Any suggestions welcome.
>

Since you are using a PC, unless you have some very apparent clues like
lots of recursive calls or very deeply nested function calls then you
probably won't be able to see the problem. If you are using some 3rd party
Database libraries or something on that order then you found the problem
by simply increasing _stklen. DOS does not automagically increase the programs'
stack like UNIX does. The stack you get at runtime is the stack you live with.



-- 
Scott Hopson   (scotth@filenet.com)
Xref: sparky comp.lang.c:14320 comp.windows.x:17292
From: klute@tommy.informatik.uni-dortmund.de (Rainer Klute)
Newsgroups: comp.lang.c,comp.windows.x
Subject: Re: Compile help
Date: 30 Sep 1992 16:15:32 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: tommy

In article <BvCCqG.JDz@unccsun.uncc.edu>, msmcknig@unccsun.uncc.edu
(Michael S McKnight) writes:
|> I am trying to compile a program for Xwindows on an HP-9000.  I have
|> the
|> following script file made to compile the program and link it in one
|> step:
|> 
|> 
|> # To Compile x2.c use this script in place of a makefile when the
|> # actual file x2.c hasnt changed, but one of the include files did.
|> 
|> cc -I/usr/openwin/include -g  -c  x2.c
|> cc -I/usr/openwin/include -g -g -o x2 x2.o -L/usr/openwin/lib  -lolgx
|> -lX11 -lm
|> 
|> # end of script

That's the trouble if you don't have Imake! Well, as I learned just
recently you must insert a space character between -L and /usr/openwin/lib
on an HP.

-- 
  Dipl.-Inform. Rainer Klute      klute@irb.informatik.uni-dortmund.de
  Univ. Dortmund, IRB
  Postfach 500500         |)|/    Tel.: +49 231 755-4663
D-W4600 Dortmund 50       |\|\    Fax : +49 231 755-2386
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.c
Subject: Re: Is there is (pascal) WITH equivalent in C?
Date: 2 Oct 92 21:13:25 GMT
Organization: CWI, Amsterdam

In article <1992Oct2.073814.27698@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:

While the comment about the code fragment is correct, the following is not:
 > 
 > Pascal's with statement is nothing more or less than syntactic sugar.
 > 
It is more than syntactic sugar:

type plist = ^list;
type list = record next, prev: precord end;
{ to implement a doubly linked list }
var a : plist;
...
{ remove a.next from the list }
	with a.next^ do
	begin
	    a.next := next;
	    next^.prev := prev;
	end;
Writing this as:
	a.next := a.next^.next;
	a.next^.next^.prev := a.next^.prev;
is wrong!  Because of this there are things that can be formulated more
simple with with statement than without.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Curses to write to stderr, possible?
Date: 5 Oct 92 21:46:38 GMT
Organization: negligable

Yeah, my suggestion has a portability problem -- anywhere that stdin
and stdout are macros instead of FILE * variables you've got problems.

On the other hand freopen() only solves half the problem, redirecting
stdout to where you want.  The other half, RESTORING it afterwards, has
no portable solution that I am aware of.  Or even a common one.  At least
my suggestion works where the stdin & stdout are variables.  Does anyone
know how to "reconnect" stdin/stdout to their original sources after
haveing been freopened()?



		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Badges?  I don' got to show you no stinkin' badges!"
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: unpredictable post-decrement behavior.
Date: 30 Sep 92 17:26:19 GMT
Organization: University of Helsinki

The productive hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <28638@vedge.UUCP> michel@vedge.UUCP (Michel Trudeau) writes:
>>herzog@ux5.lbl.gov (Hanan M. Herzog) writes:
>>: 	         product *= (double)(4 * n * n) / ((4 * n * n++) - 1);
[...]
>>   In 'C', unpredictable means undefined behavior.
>>
>
>The behavior for n++ is NOT undefined or unpredictible.  

Sorry, in this case it is.  The exact time when the increment happens is
undefined, except that it happens before the next sequence point.  It is
also an error to use the value of n before the said sequence point,
since it doesn't have a predictable (for the user) value.  FAQ, 3.1.

BTW, is there any particular reason why so many people want to put
quotes around C, when they are perfectly happy to leave all other names
in peace?

--
Lars.Wirzenius@helsinki.fi
From: Bob_Beckwith@NeXT.COM (Bob Beckwith)
Newsgroups: comp.lang.c
Subject: Re: unpredictable post-decrement behavior.
Date: 2 Oct 92 21:46:47 GMT
Reply-To: Bob_Beckwith@NeXT.COM (Bob Beckwith)

In article <316@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
> In article <28638@vedge.UUCP> michel@vedge.UUCP (Michel Trudeau) writes:
> >herzog@ux5.lbl.gov (Hanan M. Herzog) writes:
> >: See this:
> >: 	         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?
> >: 
> >   In 'C', unpredictable means undefined behavior.
> >
> 
> The behavior for n++ is NOT undefined or unpredictible.  The problem
> is the some compilers are broken.  Either the expression parsing is
> broken or (most likely) the optimization is getting a little over
> enthusiastic.  Either way, the compiler is broken.

In the original example:

  product *= (double)(4 * n * n) / ((4 * n * n++) - 1);

the result IS undefined. It is undefined because the order of evaluation of  
various subexpressions within the expression is undefined (and the value of `n'  
can therefore vary, depending upon the order of evaluation). The compiler is  
NOT broken (at least it probably isn't in this particular case :-), the code is  
broken. More specifically, the compiler is free to evaluate either

(4 * n * n) -or- (4 * n * n++)

"first". If the latter is evaluated first, the value of `n' will be one greater  
than if the former had been evaluated first. Moreover, within the subexpression  
(4 * n * n++), (4 * n) could be evaluated before or after (n++), with obviously  
differing results.

  Hope this helps!

  --Bob

Bob_Beckwith@NeXT.COM
Digital Hardware Engineering
NeXT Computer, Inc.
900 Chesapeake Drive
Redwood City, CA 94063 USA
From: jurlwin@gandalf.UMCS.Maine.EDU (Jeff Urlwin)
Newsgroups: comp.lang.c
Subject: Re: Stack Overflow ( HELP PLEASE )
Date: 5 Oct 92 15:09:39 GMT
Organization: University of Maine, Department of Computer Science

In article <BvMrJ3.22F@news.cso.uiuc.edu> gordon@osiris.cso.uiuc.edu (John Gordon) writes:
>cs125b52@ih-nxt01 (cs125 student) writes:
>
>>     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. 
>
>	extern unsigned _stklen = 64000;
>
This is assuming the Borland C Compiler.

If you're using the MS compiler the size is a parameter to the linker
/STACK:XXXX

Jeff



-- 
--------------------------------------
jurlwin@gandalf.umcs.maine.edu
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Strange memory allocation error on exiting C program
Date: 29 Sep 92 21:14:54 GMT
Article-I.D.: ulogic.310
Organization: negligable

In article <DY96E2S@mailgzrz.tu-berlin.de> jaenicke@emserver.ee.tu-berlin.de (Lutz Jaenicke) writes:
>In article <1992Sep21.020920.16101@news.cs.brandeis.edu> alexp@chaos.cs.brandeis.edu (Alex Prengel) writes:
>>
>>It basically mallocs up a bunch of memory to generate the index, and writes
>>the strings out as it goes through them. Everything works normally for
>>input files up to about 2 Meg or so. At around 2.5 Meg, the program runs
>>and writes out the output, then hangs right at the very end with the
>>message:
>>
>>Memory allocation error
>>Cannot load COMMAND, system halted
>
>Hmm, that sounds like a DOS message rather than a message from your C
>runtime system. DOS found an internal error in it's memory management
>and hence could not reload the command interpreter COMMAND.COM.

It sounds like you might not have malloc'd enough memory & started writing 
over the system's memory somewhere along the line.  When the program ends
it has trouble reloading COMMAND.COM.  It may even have come to a normal
end!  Adding free() calls would have no effect on a problem like this.  Go 
back and make certain you're allocating enough memory for the strings
you're reading from the file....

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Moderation in all things....		         ....especially moderation.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Probably a simple realloc() question
Date: 5 Oct 92 21:52:29 GMT
Organization: negligable

I'll have to admit that the routine submitted would break if the failure
occurred on upsizing -- there should be an additional test to check the
size of the existing block against the size of the request.

The original discussion was about what the behavior should be upon
trying to realloc() a memory block SMALLER than it currently was and
the point still stands: there is NO reason for such an attempt to fail.

As you said it had better return at least as much as you ask for, and
                                 ^^^^^^^^
returning the original pointer upon failure to allocate a separate,
smaller, block accomplishes this.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Blasting, bursting, billowing forth with	|
the power of ten billion butterfly sneezes,	|	-Richard Hartman	
Man, with his flaming fire,			|	hartman@uLogic.COM
has conquered the wayword breezes.		|

Xref: sparky comp.lang.c:14555 comp.lang.c++:14544 comp.std.c:2791 comp.std.c++:1314