HDTenEightyP/NetNews huggingface dataset:
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: return vs. exit(), ANSI vs. POSIX
Organization: /etc/organization
Date: Mon, 28 Sep 1992 18:28:46 GMT

In article <1992Sep25.141556.7799@news2.cis.umn.edu> fin@unet.umn.edu (Craig A. Finseth) writes:
>
>Personal opinion follows:
>
>	Considering that return from main() is handled specially by
>	the compiler, I consider _any_ recursive invocation of main()
>	to be suspect and hence not reasonable.
>
>	Why? Think for a moment: this is one of those cases that is
>	just begging to be badly handled by a compiler writer.  Who
>	needs this sort of grief?
>
>End personal opinion.  Return to usual sweeping generalizations (:-).

You are already making sweeping generalizations.  Although there are a
few compilers that have special case handling for main, there is no
requirment that this be so.  The traditional C compiliers handled
main() just like any other function.  The only thing that distinguished
main from any other function was that was the name that library setup
called after it had completed everything else.  The compiler itself did
not do anything special for the name "main".  For a lot of hardware,
the calling sequence does not really care if the actual number of
parameters passed and declared match exactly.  Prior to ANSI it was
almost amnidatory that stack/call sequences were designed to handle
such mismatches.  Certainly I have only ever used one compiler that
actually generated special code for the name "main".
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: realloc() unable to allocate
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Sat, 3 Oct 1992 04:34:35 GMT

In article <BvIJJz.BpD@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard) writes:
>If realloc() is unable to allocate the larger space desired, what happens?
>7.10.3.4 says:  "...  If the space cannot be allocated, the object pointed
>    to by ptr is unchanged.  ..."
>and  "The realloc function returns either a null pointer or a pointer to the
>    possible moved allocated space".
>While it SEEMS apparent that the meaning is that if realloc() cannot allocate
>more space, it would return the NULL pointer

The first paragraph in ANSI 4.10.3 (Memory management functions) says:
"If the space cannot be allocated, a null pointer is returned."
If the program wants to remember where the existing allocation is, it
has to keep that in another pointer.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
From: michi@ptcburp.ptcbu.oz.au (Michael Henning)
Newsgroups: comp.std.c
Subject: Re: strtoul on negative numbers
Date: 30 Sep 92 23:48:08 GMT
Organization: Pyramid Technology Corporation

jss@lucid.com (Jerry Schwarz) writes:

>What is the result of 
>  
>    strtoul("-2", (char**)0, 10)

>The description is clear that the minus sign is allowed.
>The relevant sentence describing the result is.
>	
>"If the correct value is outside the range of representable values
>ULONG_MAX is returned ..."

>My reading of this is that it requires ULONG_MAX to be returned,
>but others think that -2 is a representable value (equal to
>ULONG_MAX-1) and so ULONG_MAX-1 should be returned. 


All implementations I have seen return ULONG_MAX - 1.
I believe that this is incorrect behaviour.
-2 is not a value representable in an unsigned long, in my opionion.

							Michi.
-- 
      -m------- Michael Henning                 +61 75 950255
    ---mmm----- Pyramid Technology              +61 75 722475 FAX
  -----mmmmm--- Research Park, Bond University  michi@ptcburp.ptcbu.oz.au
-------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA   uunet!munnari!ptcburp.oz!michi
Newsgroups: comp.std.c
From: uddeborg@sisu.se (Goeran Uddeborg)
Subject: Re: should abs() be 'uint'?
Organization: Swedish Institute of Systems Development
Date: Mon, 28 Sep 1992 16:24:22 GMT

In article <Bv7uL7.2IK@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <eyal.717552134@ise> eyal@echo.canberra.edu.au (Eyal Lebedinsky) writes:
>>If the function was 'unsigned int' then the result would ALWAYS fit into
>>the return type...
>
>It would make sense.  Unfortunately, that's not the way abs() was defined
>originally... and changing it now might break a lot of code.

It could hardly break a lot of code, could it?  The change would
increase the domain of the abs() function by one value.  Nothing that
worked previously would stop working.  (Unless somebody actually
depend on abs() returning a negative value for one particular input
value, but do they really want to protect that kind of code?  Is it
even defined that way in the standard?)
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: why is va_start(p, char/short/float) illegal?
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Tue, 29 Sep 1992 00:01:32 GMT

In article <spuler.717666010@coral> spuler@coral.cs.jcu.edu.au (David Spuler) writes:
>The ANSI standard says in Section 7.8.1.1 with regard to the macro:
>va_start(ap,parmN)

That's ISO section 7.8.1.1  :-)   (ANSI section 4.8.1.1)

>"If the parameter parmN is declared .... with a type that is not compatible
>with the type that results after the application of the default argument
>promotions,the behavior is undefined."
>Sorry if this is discussed in the "rationale", but I haven't a copy of it.

Yeah, why is ISO so "irrationale" about this  :-)
The rationale says that it's for the convenience of older implementations,
so that the implementation of va_start can itself be coded in standard C,
hacked in and understood by the rest of the older implementation.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.std.c
From: jss@lucid.com (Jerry Schwarz)
Subject: strtoul on negative numbers
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid Inc.
Date: Wed, 30 Sep 92 17:58:35 GMT

What is the result of 
  
    strtoul("-2", (char**)0, 10)

The description is clear that the minus sign is allowed.
The relevant sentence describing the result is.
	
"If the correct value is outside the range of representable values
ULONG_MAX is returned ..."

My reading of this is that it requires ULONG_MAX to be returned,
but others think that -2 is a representable value (equal to
ULONG_MAX-1) and so ULONG_MAX-1 should be returned. 

  -- Jerry Schwarz















Newsgroups: comp.std.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Change to time() fn?
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 2 Oct 1992 08:41:52 GMT

greyham@research.canon.oz.au (Graham Stoney) writes:

>alpha@waggen.twuug.com (Joe Wright) writes:
>>Please remember that floats (and doubles) are approximates.
>>The value of time_t must be precise.  We don't like a value
>>which says 'it's almost 5 o'clock'.  Precision requires
>>time_t to be an integer.
>
>But time is a continuum; it is not discrete.

Do you have any evidence to support this assertion?

People thought the same thing about water for a long time.

(Follow-ups might be better off directed to sci.physics :-)

-- 
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: bernard@cpio1.fr.mugnet.org (Bernard Fouche)
Newsgroups: comp.std.c
Subject: Re: Change to time() fn?
Date: 26 Sep 92 15:34:21 GMT
Organization: CPIO S.A.


In article <1992Sep17.120636.29070@linus.mitre.org>, jrv@truth.uucp (Vanzandt) writes:
> It seems to me that time_t should be a double.  It would allow representation
> of any time during the life of the universe, with good resolution (microseconds)
> for times near the present.  I haven't seen a copy of the standard.  Would
> such an implementation conform?  Surely it's possible for a conforming
> implementation to represent my birthday?  (hint: before 1970).  (There were
> a few astronomical events of interest before 1970, too.)


That's wrong. Using a floating point representation for precise data
like this is very dangerous.

I compiled this code on a 486 running Dell Unix System V R4.0 :

main()
{
	double	a=1000000000000000.0;
	double	b=10000000000000000.0;
	
	printf("a=%f.\n",a);
	a+=1;
	printf("a=%f.\n",a);

	printf("b=%f.\n",b);
	b+=1;
	printf("b=%f.\n",b);
}

Here are the results :

a=1000000000000000.000000.
a=1000000000000001.000000.
b=10000000000000000.000000.
b=10000000000000000.000000.

As you see, "1" is too "far away" from b value to be taken into
consideration by the add operation : adding it to b doesn't change the
mantissa value. If the floating poing mecanism can manage numbers of a
huge size, it's by loosing accuracy is some situations.

To use floating points numbers without understanding this, is often a
way to produce wrong results without knowing why. (for instance
designing a financial package built over floating point numbers with a
small mantissa).

The solution is to use what's call "big numbers" : numbers that can
allow you to perform your calculations of nearly any types with
accuracy but are not (yet ?) directly known by the micro-processor, as
integers are or as (when using a math co-processor) floating points
numbers are.

When you use "big numbers", you are trading speed (you need to use
librairies and not directly processor's intructions to manipulate the
date) for accuracy.


-- 
--------------------------------------------------------------------------
Bernard Fouche  VOX   : +(33) (1) 48.04.56.30  FAX :  (33) (1) 48.04.98.95
Email : bernard@cpio1.fr.mugnet.org
Postal Mail : CPIO S.A., 13-15 Rue de la Verrerie, 75004 Paris, France
Newsgroups: comp.std.c
From: alpha@waggen.twuug.com (Joe Wright)
Subject: Re: Change to time() fn?
Organization: ALPHA, Box 68621, Va. Beach, VA 23455
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 30 Sep 1992 03:48:13 GMT

Please remember that floats (and doubles) are approximates.
The value of time_t must be precise.  We don't like a value
which says 'it's almost 5 o'clock'.  Precision requires
time_t to be an integer.
-- 
Joe Wright  alpha@waggen.twuug.com  
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: this unsigned business
Organization: TauMetric Corporation
Date: Sat, 3 Oct 1992 16:26:25 GMT

phil@ux1.cso.uiuc.edu (Phil Howard) writes:

|friedl@mtndew.Tustin.CA.US (Stephen Friedl) writes:

|>		if ( (unsigned int) vu > 100)
|>			printf("value out of range!\n");

|Is the presentation of "100" as a constant guaranteed to be correct, or
|might it be ever so slightly better to use "100U"?

It can't possibly make any difference.  100 and 100U are required to
have the same number of bits and the same bit pattern.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Subject: Re: C-formattors (problems with very long lines)
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
Date: Fri, 2 Oct 1992 17:07:54 GMT

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

>The question now is, does the below program correctly transforms
>any compilable C-source into also compilable C-source.

No, it won't work at all on systems which don't use ASCII encoding (use
'\'' if you mean a single quote, not 39). It also won't work if you
have unmatched double quotes inside of strings, single quotes inside of character
constants or either of them inside of comments. The problem with
preprocessor lines has already been mentioned. It also will get into an
endless loop if char is unsigned by default or if EOF is not defined as
-1. Maybe there are other problems, too, but this should suffice for
now :-)
-- 
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.c
Subject: Re: should abs() be 'uint'?
Date: 30 Sep 92 19:35:37 GMT
Organization: U of Toronto Zoology

In article <1992Sep30.040719.2852@waggen.twuug.com> alpha@waggen.twuug.com (Joe Wright) writes:
>Aren't we missing the point here?  The whole point of abs() is
>to take a signed value and return a positive result...
>If the tested value can actually range to -32768 (16 bits) we are
>using the wrong type.  Use the next larger type (long?) instead.

Either making the returned value unsigned or using a larger signed type
would make sense *if we were starting from scratch*.  It is not feasible
to change the type of the existing abs() function, however; the mistake
was made long ago and it is too late to fix it.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.c
From: alpha@waggen.twuug.com (Joe Wright)
Subject: Re: return vs. exit(), ANSI vs. POSIX
Organization: ALPHA, Box 68621, Va. Beach, VA 23455
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 30 Sep 1992 03:36:40 GMT

Dunno about yours, my compiler does all sorts of housekeeping
and command line parsing before calling main:.  The return from
main: falls into exit: and sets errno, closes open files and
then gracefully quits.  Returning from main() and calling exit()
have the same effect.  From main(), 'return 0;' and 'exit(0);'
are identical.  exit() is a function call and its argument is
stacked.  The exit() routine itself ignores the stack and takes
its argument from a register as if 'return' was encountered or
main() simply fell to the closing '}' brace.  exit() resets the
stack pointer as it was when the program was first executed.

-- 
Joe Wright  alpha@waggen.twuug.com  
Newsgroups: comp.std.c
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: should abs() be 'uint'?
Date: Sun, 27 Sep 1992 02:51:05 GMT
Organization: U of Toronto Zoology

In article <eyal.717552134@ise> eyal@echo.canberra.edu.au (Eyal Lebedinsky) writes:
>If the function was 'unsigned int' then the result would ALWAYS fit into
>the return type...

It would make sense.  Unfortunately, that's not the way abs() was defined
originally... and changing it now might break a lot of code.  One of
X3J11's main guidelines was "do not break legal, working, portable code".
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
From: pmontgom@math.orst.edu (Peter Montgomery)
Newsgroups: comp.std.c
Subject: Re: should abs() be 'uint'?
Date: 28 Sep 92 19:03:26 GMT
Organization: Oregon State University Math Department

In article <1992Sep28.162422.26386@sics.se> uddeborg@sisu.se
(Goeran Uddeborg) writes (regarding making abs() returned unsigned int)

>It could hardly break a lot of code, could it?  The change would
>increase the domain of the abs() function by one value.  Nothing that
>worked previously would stop working.

        Statements like

        int x, y;
        if (100 - abs(x) < abs(y)) { ...

would behave differently if abs is unsigned.  For example,
suppose x = 200 and y = 50.  The test

        100 - 200 < 50

succeeds if the operands are signed but fails if they are unsigned,
since 100 - 200 is a huge positive quantity.

        For compatibility, one might introduce uabs and ulabs
which behave like the current abs and labs but return unsigned types.

-- 
        Peter L. Montgomery              Internet: pmontgom@math.orst.edu
        Dept. of Mathematics, Oregon State Univ, Corvallis, OR 97331-4605 USA
``Who do you trust?''  Those whom I trust know English spelling and grammar.
Our economy needs more business, not more Bushiness.
Newsgroups: comp.std.c
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: this unsigned business
Date: Fri, 2 Oct 1992 15:46:00 GMT
Organization: U of Toronto Zoology

In article <711@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Stephen Friedl) writes:
>		if ( (unsigned int) vu > 100)

This is a bit arcane, but it is portable.  Both in a legalistic sense --
it is legal and proper ANSI C -- and in a practical sense -- this kind of
code has been in use for a long time (notably in the Unix kernel) and a
C compiler that botched it should have been noticed and fixed.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: Re: should abs() be 'uint'?
Date: Sun, 4 Oct 1992 09:01:12 GMT
Organization: None, Mt. Laurel, NJ

In article <eyal.717980448@ise> eyal@echo.canberra.edu.au (Eyal Lebedinsky) writes:
: Anyone else has pet problems with abs?

Not here. I'm not foolish enough to try to use a function for
something it isn't designed to do. If you want an unsigned abs
function, for goddess' sake WRITE one. Don't waste your and our
time bitching about the existing function.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
Newsgroups: comp.std.c
From: alpha@waggen.twuug.com (Joe Wright)
Subject: Re: should abs() be 'uint'?
Organization: ALPHA, Box 68621, Va. Beach, VA 23455
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 30 Sep 1992 04:07:19 GMT

Aren't we missing the point here?  The whole point of abs() is
to take a signed value and return a positive result.  The only
two's complement number that gives a problem is the 'most negative'
0x80..00 because it does not have a positive counterpart.  So what?
If the tested value can actually range to -32768 (16 bits) we are
using the wrong type.  Use the next larger type (long?) instead.
-- 
Joe Wright  alpha@waggen.twuug.com  
Newsgroups: comp.std.c
From: david@kai.com (David Nelson)
Subject: order of sequence points in subexpressions
Summary: What is the relationship between sequence points in different subexpressions
Keywords: sequence points
Organization: Kuck and Associates, Champaign IL
Date: Tue, 29 Sep 1992 22:25:21 GMT

We all know that "x = y[++i] + z[++i];" is asking for trouble. But what
about: "a = b[i+=1,i] + c[i+=1,i];". The comma operators have introduced
sequence points.

From ANSI 2.1.2.3 Program Execution
 ... At certain specified points in the execution sequence called sequence
 points, all side effects of previous evaluations shall be complete and no
 side effects of subsequent evaluations shall have taken place.

From ANSI 3.3 Expressions
     Between the previous and next sequence point an object shall have its
 stored value modified at most once by the evaluation of an expression. 
 ...
     Except as indicated by the syntax or otherwise specified later (for the
 function-call operator (), &&, ||, ?:, and comma operators), the order of
 evaluation of subexpressions and the order in which side effects take place
 are both unspecified.

For my hypothetical implementation, I choose to implement evaluation of the
subexpressions to '+' in parallel. With the second example, there are a
couple extra sequence points to worry about. But is there any relationship
between the two sequence points, or does the sequence point at the comma
operator only affect the subexpressions to the comma.

My interpretation would be that the sequence point only affects the
subexpression of the operation that introduced the sequence point. Anyone
care to confirm or reject this interpretation.

David Nelson               UUCP:      ...!uunet!kailand!dnelson
Kuck and Associates        Internet:  dnelson@kai.com 
1906 Fox Drive		   #include <std/disclaimer>
Champaign, IL   61820      Optimizing software for super computers
Newsgroups: comp.std.c
From: prangba@halcyon.com (Bruce Prang)
Subject: Sorting of x,y coords.
Organization: Northwest Nexus Inc. (206) 455-3505
Date: Thu, 1 Oct 1992 22:41:14 GMT

Does anybody out there in net-land have any routines, or know where I
can get some, for sorting x,y coordinate pairs. I want to sort these
pairs so the resulting order is circular. That is, if you were to
connect all of the points with straight lines none of these lines would
cross.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.emacs
Subject: Re: Can replace-regexp re-scan it's input?
Date: 29 Sep 1992 04:01:05 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Sep25.000308.26805@aimla.com> walter@optimla.aimla.com (Walter Hunt) writes:
>	But can I do a loop within a macro? Possibly using some version of
>eval-expression? I didn't realize that replace-regexp didn't return a value -
>maybe that's why my attempt at a loop never finished :( ?

You can't really do loops within keyboard macros.  You could write Lisp
code that contains a loop, or you could give a numeric repeat count
argument to the keyboard macro.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.emacs:3247 comp.editors:2390 comp.lang.prolog:1821
From: frechett@spot.Colorado.EDU (-=Runaway Daemon=-)
Newsgroups: comp.emacs,comp.editors,comp.lang.prolog
Subject: Re: Customizing Emacs to look like VI (yes!)
Keywords: Emacs, Quintus Prolog, Vi, MockLisp, key bindings
Date: 2 Oct 92 01:47:07 GMT
Organization: University of Colorado, Boulder

>From: ederveen@athena.research.ptt.nl (Ederveen D.)
> Subject: Customizing Emacs to look like VI (yes!)
>
> Yes, really, I'm looking for a key bindings or MockLisp-functions
> that make Emacs look or feel like vi. I'm using Quintus Prolog on
> VAX/VMS...

Sorry I didn't catch the original post, but why don't you just 
compile elvis and be done with it?  It's a good vi clone (IMO) and
it's got an advantage of many of the other clones in that it's 
brain dead simple to compile on a VMS machine.  I've got a whole
horde of people using it now, because they either don't like
emacs at all or they like gnuemacs and all we have is unipress.

Elvis can be found everywhere.. ;)

	ian
From: shankar@sgi.com (Shankar Unni)
Newsgroups: comp.emacs
Subject: Re: Backward-delete in overwrite mode
Date: 30 Sep 1992 22:07:58 GMT
Organization: Silicon Graphics, Inc.
Distribution: comp
NNTP-Posting-Host: boris.wpd.sgi.com
X-Newsreader: Tin 1.1 PL5

Marc Girod (girod@tele.nokia.fi) wrote:

> I tried what I thought was the natural way, something like:
> (define-key overwrite-mode-map "\C-?" 'backward-char)
> but I was surprised to get as result:
> Symbol's value as variable is void: overwrite-mode-map

Not surprising - overwrite-mode is not a major-mode, as its name might
imply - it's basically a built-in flag checked by (self-insert-internal).


To accomplish what you want, you may want to put some hooks into
a function, say, (toggle-overwrite-mode):

(defun toggle-overwrite-mode()
   "toggle overwrite-mode flag"
   (interactive)
   (cond
   (setq overwrite-mode (not overwrite-mode))
)

Within this function, you could put code to save off the original
keybinding of "delete", and set it to backward-char when going into
overwrite-mode, and do the reverse when toggling out.  (exercise for
the reader - I'm too lazy today :-)

Of course, if you manually (setq overwrite-mode t), you lose..

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-390-2072