HDTenEightyP/NetNews huggingface dataset:
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: (long) x and (long) floor(x)
Date: 14 Dec 92 17:48:10 EST

pjh@cs.tut.fi (Haavisto Petri) writes:
>I just spent several hours debugging a simple program and before
>crying Compiler Bug I would like to make sure that there is one.
>I don't have the standard, but it seems clear to me that given an
>expression of type double with a positive value, the following
>should always be true:
>		(long) (expression) == (long) floor(expression)
>Does the standard guarantee this or is there a loop hole that has to
>do with finite precision arithmetic and which allows the compiler to
>do what it chooses?

The most obvious thought is:  do you have a proper prototype for floor()
in scope at that point?  If not, you can expect random results.

The second most obvious thought:
"If the integral part of the double cannot be represented by the integral
type, the behavior is undefined."  So, if the expression's value is 5.0E+9
on a system with 32-bit longs, then acceptable runtime behavior would include
growing long red tentacles and slapping you silly, or returning the current
time, or whatever (especially including calculating two different numbers,
and there are plausible reasons why it could).

If floor() is in scope and properly declared, and the expression is in the
range of the representation of long, then you have a compiler bug (which 
will surprise no one :-).
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: are float functions (sinf, fabsf) required by ansi?
Summary: no
Date: 19 Dec 92 18:41:28 GMT

In article <1992Dec18.232621.2801@bernina.ethz.ch>, hoesel@igc.ethz.ch (Frans van Hoesel) writes:
> The subject is clear enough... must any ansi compiler know the functions
> for evaluating sin with a float argument (after including math.h) and
> is it always called sinf. Or rephrased... is sinf in the standard library?

No.  ANSI reserves the names for (the obvious) future use but does not
require them.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
Is it too much to ask for an occasional token
gesture of appreciation?! -- Calvin
From: boyne@hplvec.LVLD.HP.COM (Art Boyne)
Date: Mon, 14 Dec 1992 20:09:41 GMT
Subject: Re: Is INT_MAX<<1 defined?
Organization: Hewlett-Packard Co., Loveland, CO
Newsgroups: comp.std.c

In comp.std.c, dik@cwi.nl (Dik T. Winter) writes:

>   What it comes down to is that << is not a mathematical operation, there
>   is nothing in mathematics that tells us that 16384 << 1 equals 32768.
>   So what is the meaning of:

I'm not so sure about that.  Conceptually, the common-usage interpretation
of the operation a << b can be represented mathematically as a*(2^b).
I can even propose a hypothetical machine that lacks a true shift instruction
and actually implements the << and >> operators by such means, especially
when b is a constant.

Given that potential implementation, it is easy to imagine that INT_MAX << 1
would generate overflow on such a machine.  Now, considering that the ANSI
standard in general places as few restrictions as possible on implementations
so as to maximize performance, I'm not sure that there is anything in the
standard that would judge this implementation as non-conforming.

Art Boyne, boyne@hplvla.lvld.hp.com
"An innocent bystander bemused by the furor of this discussion"
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: mathematical modulo operation
Organization: SoftQuad Inc., Toronto, Canada
Date: Sat, 12 Dec 92 23:11:15 GMT

I've found the persistence of this thread surprising.  To my mind,
the answer to the original question

| Is this implementation of the modulo function guaranteed [to work?]
| int mod(int j,int N) {return((((j)%N) < 0) ? ((j) % N)+N : ((j) % N));}
 
is clearly Yes.  The counter-argument

> Strictly speaking, the implementation is free to define which of two
> allowed results is produced for % when the divisor is negative.  I don't
> know any implementation where the implementation definition might say that
> the result alternates from one invocation to the next, but it's not clear
> if the standard allows it.

seems entirely specious to me.  What section 3.3.5/6.3.5 actually says is
the following; I have added emphasis.

#  If either operand is negative, WHETHER THE RESULT of the / operator
#  IS the largest integer less than or equal to the algebraic quotient
#  OR the smallest integer greater than or equal to the algebraic
#  quotient IS IMPLEMENTATION-DEFINED, as is the sign of the result
#  of the % operator.  If the quotient a/b is representable, the
#  expression (a/b)*b + a%b shall equal a.

To me this clearly means that the implementation must define it as one
value or the other.  If it was intended that it could vary from one to
another from one instance of the operation to another, then there would
be no point in making it implementation-defined at all; the standard
might as well have said that it was unspecified, the way it does for
evaluation order.

By wording it as it does, the standard is, precisely, allowing for
functions such as the one mentioned above.

It's still a puzzle to me why, having provided the above definition,
they then proceeded to specify the library functions div() and ldiv()
as they did, but not provide functions that would provide the mathematical
modulo function, which I think is more useful.  But this is incidental.
-- 
Mark Brader			"Could you please continue the petty bickering?
SoftQuad Inc., Toronto		 I find it most intriguing."
utzoo!sq!msb, msb@sq.com		-- Data ("Haven", ST:TNG, Tracy Torme)

This article is in the public domain.
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Is INT_MAX<<1 defined?
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 14 Dec 1992 00:52:58 GMT

In article <1992Dec11.173855.19517@crd.ge.com> volpe@ausable.crd.ge.com writes:
>Section 3.3 says "These [bitwise] operators return values that depend on the
>internal representations of integers, and thus have implementation defined
>aspects for signed types."

Yeah, this means that even when the operation succeeds, the resulting VALUE
still has implementation defined aspects.  It doesn't say anything about
failed operations.

>The standard makes an explicit statement showing a qualitative difference
>between bitwise operators and non-bitwise operators,

Yes.

>indicating that bitwise operators operate in "representation-space" while
>other operators operate in "math-space". 

I don't think the standard says this so clearly.  We can't even rely on the
base document to answer this, because in pre-standard days of a substitute
assembly language, I think ALL operators were regarded as operating in
representation-space.  If you think the standard maintained the old concept
in a fragment of C's operations, I think you have to ask for an interpretation
ruling.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: "peter curran" <peter.curran@canrem.com>
Subject: <iso646.h>
Reply-To: "peter curran" <peter.curran@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 17 Dec 92 14:38:37 EST


Re: <iso646.h>

It seems to me that this is a reasonable solution (if I understand
it correctly).

Note that if your code does not include the <iso646.h> header file,
it does not affect you at all.  This is a key point, and differs from
the trigraph situation, where anyone can be bitten (although the
chances are pretty small), whether s/he knows about them or not.

On the other hand, if you are in an environment where some or all of
the "national" characters have been redefined, making the standard
ASCII graphics unavailable, there are now standard substitutions that
are reasonably readable (at least in English!), less ugly than
trigraphs, and that you can get used to consistently in all code.
Without this proposal, everyone affected by the problem would [do] no
doubt adopt their own macros, degrading the readability of their code.

Peter Curran
Usenet: peter.curran@canrem.com     RIME: CRS (#118)
---
  DeLuxe 1.25 #12339  
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: typedef void (*generic)()
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 17 Dec 1992 01:23:16 GMT

In article <1992Dec16.172748.24120@bernina.ethz.ch> hoesel@igc.ethz.ch (Frans van Hoesel) writes:
>I have a problem in doing what I want to do in c.
>#include <stdio.h>
>#include <stdlib.h>
>typedef void (*generic)();
>main() {
>        generic f,g;
>        int     i;
>        f = (generic) printf;
>        g = (generic) abs;
>	i=-4;
>	/* and now do something like :printf("some text %d\n",abs(i)
>	  ), but using f and g instead !*/
>}
>This isn't the right group to ask (I know), but propably the best
>There is also a remark from my compiler on some constructs stating that
>void pointer cannot be cast to function pointers. Is this allowed?

Pointers to object or incomplete types cannot be converted to pointers
to function types, nor vice-versa (except for the special case of
null pointer constants being converted to pointers to function types).

However, any pointer to function type can be converted to any other
pointer to function type.  You have to convert it back before calling
though.  So in this sense, your generic type is indeed generic.

You can do this:
    ((int (*) (char *, ...)) f) ( "some text %d\n",
                                  ((int (*) (int)) g) (i)
                                );
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: (long) x and (long) floor(x)
Organization: TauMetric Corporation
Date: Thu, 17 Dec 1992 18:05:08 GMT

gordon@delfin.com (Gordon Hua) writes:

>In article <1ghtanINNcf9@cs.tut.fi> pjh@cs.tut.fi (Haavisto Petri) writes:

>>I don't have the standard, but it seems clear to me that ...

>I also don't have the standard, but I have observed that ...

It seems to me that it would be a better use of net bandwidth,
particularly in comp.STD.c, if questions about the Standard were
answered by references to the Standard.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: C VS Fortran on UNIX
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 21 Dec 1992 02:07:30 GMT

In article <1992Dec19.151202.45788@kuhub.cc.ukans.edu> christos@kuhub.cc.ukans.edu writes:
>	I am going to write a program for number crunching on UNIX.

The C standard defines a few functions that might help number crunchers.

>I am considering between Fortan and C

The C standard says nothing about Fortran.

>and I am wondering which one would be faster or

The C standard says nothing about speed.

I vote again for the comp.lang.c faq to be cross-posted to this newsgroup.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: Can one get the rationale?
Organization: University of Helsinki
Date: Fri, 18 Dec 1992 17:04:41 GMT

spencer@panix.com (David Spencer) writes:
>Is there an underground source for the rationale -- 

I've bought the Rationale (but not the standard).  According to the
data in the book, it is published by Silicon Press, and has ISBN
0-929306-07-4.  The address given in the book is

	Silicon Press
	25 Beverly Road
	Summig, NJ 07901, USA

It cost me 80 Finnish marks, which is about 16 US dollars, but that
was when the store was trying to get rid of it.  It is a thinnish book
(about 120 pages), white cover, about two centimeters higher than K&R.
The full title is "Rationale for the ANSI C Programming Language".

I don't know if it is still available.

Incidentally, that store---one of the best in Finland---hadn't ever
even heard of the standard itself.  Sigh.  But on the other hand, they
have shelves of books that claim that NULL is defined as '\0' in
<stdlib.h> and there only, or other stupid things like that. :-(

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Newsgroups: comp.std.c
From: mcdaniel@grex.ann-arbor.mi.us (Tim McDaniel)
Subject: Re: <iso646.h>
Keywords: Standard C international header implementation
Organization: GREX Public Access Unix +1 313 761 3000
Date: Sun, 13 Dec 1992 20:43:29 GMT

What is a "normative addendum"?

What insane asylum added digraphs to the existing trigraph mess, and
also said that the "difficult" characters have to exist anyway?  What's
the point of trigraphs and digraphs then?

What fool made these identifiers ("or", "ne", ...) reserved?  "If you
want PL/I ..." and all that.  (Designing a language from scratch, I
would have used "and", "or", et cetera.  But C didn't, but now we have
both.)

-- 
Tim McDaniel
Internet: mcdaniel@{grex,m-net}.ann-arbor.mi.us, mcdaniel@adi.com
From: diamond@jit533.jit.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: Contradiction wrt arrays
Date: 15 Dec 92 05:01:49 GMT
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo

In article <1gj22rINNe9d@falcon.natinst.com> erik@natinst.com (Erik Crank) writes:
>        char a[N];
>(1)     &a[N];
>(2)     a[N];
>If expression (1) is legal (which is implied by the Rationale 3.3.6)
>then I claim that expression (2) should also be legal, although it isn't [...]
[...]
>By "is legal" I mean "has defined behavior".
>My reasoning is as follows:
>        1. &a[N] is valid iff &(*(a+N)) is valid.
>           (by definition of array subscripting [3.3.2.1])

Yup.

>        2. &(*(a+N)) is valid iff *(a+N) is valid.
>           (by definition of indirection operator [3.3.3.2])

By definition of address operator [also 3.3.3.2], &(*(a+N)) is valid iff
*(a+N) is either a function designator or an lvalue that designates an
object that is not a bit-field and is not declared with the register
storage-class specifier.  In fact, *(a+N) is not a function designator
and is not an lvalue that designates an object.

Therefore &a[N] is invalid.  You've proven that the Rationale is wrong
here.  Fortunately (:-s) the Rationale isn't part of the Standard.

The desired result can be obtained by the expression a+N.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: Assignment operator and volatile
Date: 14 Dec 1992 02:16:35 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1992Dec13.215752.29143@softway.sw.oz.au>
peterc@suite.sw.oz.au (Peter Chubb) writes:
>#define	ap	((volatile char *)0x1234)
>	*ap = *ap = 1;

(Side issue: I would be much happier with this if it were, e.g.,

	char v;
	v = *ap = 1;

so that there are not two independent writes to *ap without an
intervening sequence point.  Ignoring that issue:)

>(where the char at 0x1234 may be write-only, and return garbage when read,)
>should a strictly conforming compiler generate a read instruction
>after its write instruction, or can it assume that immediately after
>the assignment, the char has the value 1?

My own interpretation is that the compiler can do as it pleases, but
must document what it does.

>	I.e., in 68000 code, 
>
>	move.l	#$1234,a0
>	move.b	#1,d0
>	move.b	d0,(a0)
>	move.b	(a0),d0	<-- Is this instruction necessary?
>	move.b	d0,(a0)

I believe this would be a valid translation both with and without
the marked line, given appropriate compiler documentation.

(Incidentally, GCC apparently uses the `re-read' interpretation.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: pjh@cs.tut.fi (Haavisto Petri)
Newsgroups: comp.std.c
Subject: Re: (long) x and (long) floor(x)
Date: 17 Dec 1992 11:26:22 GMT
Organization: Tampere University of Technology
Distribution: world
NNTP-Posting-Host: vuoripyy.cs.tut.fi

In article <1992Dec16.213428.2832@delfin.com> gordon@delfin.com writes:
>In article <1ghtanINNcf9@cs.tut.fi> pjh@cs.tut.fi (Haavisto Petri) writes:
>
>>I don't have the standard, but it seems clear to me that given an
>>expression of type double with a positive value, the following
>>should always be true:
>>
>>		(long) (expression) == (long) floor(expression)
>
>I also don't have the standard, but I have observed that the above will
>fail for cases where the expression is negative.

Yes. The corresponding condition for negative expressions is

		(long) (expression) == (long) ceil(expression)

Several people have pointed out that my example "fails" with negative
expressions. I understand this very well and that is why I specifically
said the expression has a positive value.

Petri Haavisto
Newsgroups: comp.std.c
From: a1001032@cdf.toronto.edu (Fiona Wong)
Subject: ANSI-C document
Originator: a1001032@eddie.cdf.toronto.edu
Organization: University of Toronto Computing Disciplines Facility
Date: Sat, 12 Dec 1992 01:04:56 GMT

Hi,netters:

	Does anyone know any ansi-C document available via anonymous ftp?
Pls show me the way! Thanx!

:-)


-- 
|       ____                    | You know you've been spending too much time |
|      /    . __   __   __      | on the computer when your friend misdatess  |
|     /--- / /  ) /  ) ___)     | a check, and you suggest adding a "++" to   |
|____/    / (__/ /  / (__(______|_fix it._____________________________________|
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: mathematical modulo operation
Date: 13 Dec 92 17:06:17 GMT

In article <1992Dec12.231115.26787@sq.sq.com>, msb@sq.sq.com (Mark Brader) writes:
> It's still a puzzle to me why, having provided the above definition,
> they then proceeded to specify the library functions div() and ldiv()
> as they did, but not provide functions that would provide the mathematical
> modulo function, which I think is more useful.  But this is incidental.

The idea behind div()/ldiv() is that many machines have a single
instruction that provides both the quotient and remainder in a single
operation, either in addition to, or instead of, instructions that
produce only one or the other.  Many algorithms require both, but it
can be quite difficult for an optimizer to recognize that that is what
is happening when the division and remainder are completely separate
operations, so the library functions were added to provide an easy way
to provide this optimization.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
I won't eat any cereal that doesn't turn the milk purple. -- Calvin
Newsgroups: comp.std.c
From: wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!)
Subject: Re: Is INT_MAX<<1 defined?
Date: Tue, 15 Dec 1992 14:21:03 GMT
Organization: MSD software vault #9 @THD

Just to raise the voice of one practicing programmer, who doesn't have the
standard at hand. What I expect to happen in expressions like these

	INT_MAX << 1

is that the compiler behaves as if it were ultralame. It acts as if it doesn't
precompute at compiletime but rather computes the result at runtime. So that 
in fact the default type for INT_MAX is signed int (since there isn't an U 
or an L anywhere) and the shifting operation operates on a signed int on that
system. For a 68000 I'd expect something that produces the same result
as this (lame) code:

	MOVE.L	#INTMAX,d0
	ASL.L	#1,d0

Obviously this may be non-portable, but so what ? If you want portability
you write  (long) INT_MAX * 2 (or somesuch).

To me any other interpretation (even if in the standard) obscures the 
C language. If you want to get a long out of INT_MAX << 1 then cast it.

Nat!
-- 
 -----   Email: wallmann@backus.pu.informatik.th-darmstadt.de  -----
               "Bang that bit that doesn't bang"   
                  VfL Bochum:  "Unabsteigbar"
From: erik@natinst.com (Erik Crank)
Newsgroups: comp.std.c
Subject: Contradiction wrt arrays
Date: 14 Dec 1992 16:32:59 -0600
Organization: National Instruments, Austin, TX
NNTP-Posting-Host: falcon.natinst.com


I'm wondering about an apparent contradiction in the standard
concerning addressing "one past the last element" of an array.

Consider the following expressions:
    {
        char a[N];

(1)     &a[N];
(2)     a[N];
    }

If expression (1) is legal (which is implied by the Rationale 3.3.6)
then I claim that expression (2) should also be legal, although it
isn't according to the standard (3.3.6).

My reasoning is as follows:
        1. &a[N] is valid iff &(*(a+N)) is valid.
           (by definition of array subscripting [3.3.2.1])

        2. &(*(a+N)) is valid iff *(a+N) is valid.
           (by definition of indirection operator [3.3.3.2])

        3. *(a+N) is valid iff a[N] is valid.
           ([3.3.2.1])
        ---------------------
        4. &a[N] is valid iff a[N] is valid. (by 1,2,3)


By "is legal" I mean "has defined behavior".

Newsgroups: comp.std.c