HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.std.c
From: flaps@csri.toronto.edu (Alan J Rosenthal)
Subject: Re: Change to time() fn?
Organization: Dynamic Graphics Project, University of Toronto
Date: 29 Sep 92 17:48:07 GMT


karl@ima.isc.com (Karl Heuer) writes:
>Unfortunately, in order to allow for implementations that have no clock, the
>Standard requires that |time()| be able to return the constant |(time_t)-1|
>to indicate failure.  Hence, |time_t| must be an arithmetic type.

Well, time_t must be a type which can be cast to and from -1.  So there's no
reason it couldn't be a struct __timeval, with a special case in the compiler,
right?  The special case would work as follows:  If you cast -1 to struct
__timeval (which you probably invoke by casting it to time_t), then it yields
an external reference to __no_timeval, which is a struct __timeval in the
library with all zeroes or whatever's convenient.  I don't think you can cast a
time_t to int or long or anything like that, but if you could, this cast could
turn into ((arg.__errorindicator == 53) ? -1 : 0) or whatever test is
appropriate.  Finally, we have comparisons: If you compare two time_t's, well
perhaps you're allowed to compare them in general, in which case this would
have to turn into a full comparison, but otherwise, it could just check whether
or not they were both __no_timeval's or both not.

Workable?
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.std.c
Subject: Re: struct hack, and other out-of-array references
Date: 30 Sep 92 06:03:16 GMT
Organization: None, Mt. Laurel, NJ

In article <1992Sep25.012337.22640@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
: > On the other hand, the various rules on objects, arrays, padding,
: > etc., do require that a doubly indexed array is also a contiguous
: > array of its elements.
:
: Contiguous, yes; array, no.  If you believe otherwise, please cite
: something in the standard to support your position.

Way back when, I noted that there was an unusual dichotomy between
object addresses and addresses in objects. Object addresses (of
objects not contained in objects) are completely independent of
one another. One can't assume anything about these except that
pointers to distinct objects (counting null as an "object") don't
compare equal. However, addresses within objects behave as if
they were in an ordinary flat address space. For example,
(char*)a[n] op (char*)a[m], (op is any relational) has the same
truth value as n op m. I asked about this during one of the
public comment periods and was told that it was intentional that
addresses within object behaved this way. (Similarly, if two
fields in a structure have a particular ordering, so do their
offsets.)

Consider the question: what is (char*)&a[0][1] - (char *)&a[0][0]?
sizeof(&a[0][0]) of course. Carried out repeatedly, one sees that
each subelement of a is at the expected offset from the start of
a. The only question you might have is: what is (char*)&a[x][0] -
(char*)&a[x-1][y-1], where y is the number of elements in a[x].
The rules on sizeof and contiguity of objects require that to be
sizeof(&a[0][0]) as well.

In other words, these pointers are just pointers into an array,
and correspond in the expected way to pointers into the doubly
indexed array.

Which is just a fancy way of saying that it is an array.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
Newsgroups: comp.std.c
From: eyal@echo.canberra.edu.au (Eyal Lebedinsky)
Subject: Re: should abs() be 'uint'?
Organization: Info Sci & Eng, University of Canberra, AUSTRALIA
Date:  1 Oct 92 23:00:48 GMT

Following my original posting on the subject, I think the gravity of the
issue
can be better viewed with examples of past problems. Of course, the
replay of 'the standards seeks backward compatibility' is valid but
should be related to 'past problems' againt 'future problems'.

My most prominent problem:
   I keep angles as 16bit signed numbers. 180 degrees (and -180) is
represented as 0x8000. I often seek the magnitude using abs(a) and got
caught a few time. Now I do things like:

d = abs (d)
if (d < 0) {
   /* handle special case */
}

which, If I leave out, will have subtle and hard to find effects. The
use of 'int' is most appropriate as I want angles to wrap around in the
range [-180, 180)

Anyone else has pet problems with abs?
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Change to time() fn?
Organization: SoftQuad Inc., Toronto, Canada
Date: Tue, 29 Sep 92 22:24:03 GMT

> Unfortunately, in order to allow for implementations that have no clock, the
> Standard requires that |time()| be able to return the constant |(time_t)-1|
> to indicate failure.  Hence, |time_t| must be an arithmetic type.

The Standard explicitly requires time_t to be an arithmetic type.
Section 4.12.1 (ANSI; 7.12.1 in ISO numbering).
-- 
Mark Brader, Toronto		"Mark is probably right about something,
utzoo!sq!msb, msb@sq.com	 but I forget what"	-- Rayan Zachariassen

This article is in the public domain.
Newsgroups: comp.std.c
From: spuler@coral.cs.jcu.edu.au (David Spuler)
Subject: why is va_start(p, char/short/float) illegal?
Organization: James Cook University
Date: 28 Sep 92 07:40:10 GMT


The ANSI standard says in Section 7.8.1.1 with regard to the macro:

va_start(ap,parmN)

that:

"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."

This prevents parmN from having char/short/float type.
My question is: why is this restriction imposed?

It seems to me that the variadic function being defined by <stdarg.h> and
va_start will have a prototype with the ellipsis function, and can assume
that all calls to it will be governed by a prototype, and therefore need
not have the default promotions applied to the named parameters.
I see no reason why the compiler can't support char/short/float types.

Sorry if this is discussed in the "rationale", but I haven't a copy of it.

Thanks for any insight,
David Spuler
--
David Spuler, James Cook University of North Queensland, Australia
Author of "Comprehensive C", Prentice-Hall, 1992, pp416, ISBN  0-13-156514-1
INTRO TOPICS: types, operators, structures, strings, fns, ptrs, files etc etc
ADVANCED TOPICS: efficiency, debugging, style, portability, large programs
Newsgroups: comp.std.c
From: bfhalls@vela.acs.oakland.edu (HALLS BRADLEY F)
Subject: ptr to a function
Organization: Oakland University, Rochester MI.
Date: Wed, 30 Sep 1992 03:46:32 GMT

Thanks to all who replied to my post about pointers to a function. I got
so many answers, I don't have time to thank everyone individually, so I
thought I would do it here. Many of you also pointed me (no pun intended)
towards comp.lang.c, and I will post future questions there.

Thanks again,

--Brad.

-- 
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Brad Halls                                "Still looking for witty quote."
Oakland University                         -me    
Rochester, Michigan
bfhalls@vela.acs.oakland.edu

^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
From: sprave@gonzo.informatik.uni-dortmund.de (Joachim Sprave)
Newsgroups: comp.std.c
Subject: Very old draft
Date: 5 Oct 1992 10:35:33 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: gonzo

Hi there,

today I accindentally found a copy of the standard
in our library :-) , but unfortunately it's
a draft from 10 Oct. 1986: X3.159-198x  :-(. 

Could someone send me a short summary of the
major changes until today ? 


-- 

         //////\\
        /        \
       _|  _   _ |_
      |.|-(.)-(.)+.|
       \|    J   |/
        \   ---  /
         \      /
          "####"
		Joachim
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: struct hack, and other out-of-array references
Organization: SoftQuad Inc., Toronto, Canada
Date: Thu, 1 Oct 92 07:03:45 GMT

> > > On the other hand, the various rules on objects, arrays, padding,
> > > etc., do require that a doubly indexed array is also a contiguous
> > > array of its elements.
> >
> > Contiguous, yes; array, no.  If you believe otherwise, please cite
> > something in the standard to support your position.
> 
> Consider the question: what is (char*)&a[0][1] - (char *)&a[0][0]?
> sizeof(&a[0][0]) of course.  Carried out repeatedly, one sees that
> each subelement of a is at the expected offset from the start of
> a.  The only question you might have is: what is (char*)&a[x][0] -
> (char*)&a[x-1][y-1], where y is the number of elements in a[x].
> The rules on sizeof and contiguity of objects require that to be
> sizeof(&a[0][0]) as well.

For ease of discussion I'll assume that a[0][0] has type int.

The above is correct as far as it goes.  And it implies that you can do

	int *p = &a[x-1][y-1];
	p = (int *) ((char *) p + 2 * sizeof (int));

and *p will now be a[x][1].  But you _cannot_ replace the second
statement with a simple "p += 2;" and expect the same result.  This
is the thrust of the Interpretation Ruling that was quoted earlier
in the thread.  You really have to make the excursion into char *
and back:  The standard requires that "a" be treatable as an array
of bytes, and therefore as an array of any character type, but not
as an array of int.

I'll make an analogy again.  If it seems bizarre that "p = (int *)
((char *) p + 2 * sizeof (int));" could be legal where "p += 2;"
is not, consider that "i = (int)(i + (long) j - k);" can be legal
where "i = i + j - k;" would not (e.g. if all 3 variables were
30000 initially and ints are 16 bits).  This is the same sort of
thing -- you have to make a temporary excursion to another type
where the operations you want to carry out have the desired range.

> In other words, these pointers are just pointers into an array,
> and correspond in the expected way to pointers into the doubly
> indexed array.

They point to locations which are located as they would be in a
simple array, but the permitted operations are not the same.
Therefore it is not an array.
-- 
Mark Brader		     "I always pass on good advice.  It's the only thing
SoftQuad Inc., Toronto	      to do with it.  It is never any use to oneself."
utzoo!sq!msb, msb@sq.com 	-- Lord Goring  (Oscar Wilde: An Ideal Husband)

This article is in the public domain.
Newsgroups: comp.std.c
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: should abs() be 'uint'?
Date: Mon, 28 Sep 1992 19:38:07 GMT
Organization: U of Toronto Zoology

In article <1992Sep28.162422.26386@sics.se> uddeborg@sisu.se (Goeran Uddeborg) writes:
>>>If the function was 'unsigned int' then the result would ALWAYS fit...
>>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...

You've missed the point.  The problem is not that one extra return value
has appeared, but that *the type of abs() has changed*.  Worse, its
signedness has changed, which puts you squarely into the fever swamp
of mixed-signed-and-unsigned expressions.  I try to avoid thinking about
that stuff, so I can't cite detailed examples off the top of my head, but
I know it's a minefield.  (It's also an area where there are already
substantial portability problems, because compilers differed.)

>... (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?)

ANSI C says "if the value won't fit, result is undefined".  This boils
down to "you cannot safely call abs() with that argument".
-- 
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: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Change to time() fn?
Date: Fri, 2 Oct 1992 15:43:55 GMT
Organization: U of Toronto Zoology

In article <1992Sep30.034813.2589@waggen.twuug.com> alpha@waggen.twuug.com (Joe Wright) writes:
>Please remember that floats (and doubles) are approximates.
>The value of time_t must be precise...

It is quite possible to manipulate precise values using doubles, if you
have well-behaved floating-point hardware (e.g. IEEE-standard).  If your
number is an integer that will fit within a double's mantissa field,
which is usually 50ish bits, the representation *is* precise.  Properly
designed floating-point hardware will give precise results when such
quantities are added, subtracted, compared, etc., given that neither final
nor intermediate results are big enough to exceed the mantissa field.
IEEE-standard FP hardware is *required* to do this right.

We do a lot of accounting software using awk, which does all its arithmetic
using doubles.  (The crucial trick is to keep everything in cents rather
than fooling around with fractional dollars.)  I assure you, we get precise
results:  our department's accountant notices if a penny is missing.

Changing time_t to a double does have problems, but this isn't one of them.
-- 
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: kanze@us-es.sel.de (James Kanze)
Subject: Re: struct hack
Organization: SEL
	<1992Sep10.153316.20804@awdprime.austin.ibm.com>
	<1992Sep19.225457.13353@jarvis.csri.toronto.edu>
Date: 2 Oct 92 21:07:40


I have been following this thread for a while, and since nobody else
seems to have said it, I will.

>>     struct fred { int i; char s [1]; } *f;
>>     char *s;
>> 
>>     /* ... */
>>     f = malloc (sizeof f + strlen (ss));

>>     f->s[1 /* or 2, or anything other than 0 */] ;

Despite all the assertions to the contrary, it seems to me that this
program does not conform to the ANSI C standards.

As is pointed out in previous posts, the pointer returned by malloc
points to an area big enough for the job.  In fact, the following
should be legal:

    char*           p = malloc( sizeof( struct fred ) + strlen( ss ) ) ;
    p += offsetof( struct fred , s ) ;
    p[ 1 /* Or anything up to the end of the malloced memory */ ]

The problem with the example is that the pointer under consideration
is *not* the pointer returned from malloc, but rather the results of
the pointer expression f->s (which has a type of char*).  Note that
this is definitely a pointer to an array object (sizeof( f->s ) == 1),
and so according to the ANSI standard, bounds checking is allowed.

In the reality, I suspect that any compiler that actually did this
would break a lot of code (including some of my own).
--
James Kanze                     GABI Software, Sarl.
email: kanze@us-es.sel.de       8 rue du Faisan
                                67000 Strasbourg
                                France

Newsgroups: comp.std.c
From: bill@twwells.com (T. William Wells)
Subject: Re: this unsigned business
Date: Thu, 1 Oct 1992 08:14:55 GMT
Organization: None, Mt. Laurel, NJ

In article <711@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Stephen Friedl) writes:
:      Let's say that I've got an int whose legal range is 0 to 100,
: and I want to validate it (say) upon entry to a function.  Is this
: a portable way to do it?
:
:       foo(v)
:       int v;
:       {
:               if ( (unsigned int) v > 100)
:                       printf("value out of range!\n");

When casting an int to an unsigned int and the value is negative,
UINT_MAX+1 is added to get the result. Your test will work
provided that the value of all negative integers, cast to
unsigned, are > 100. Since that the two types are of the same
size and that a pure binary representation must be used,
excepting the signed bit, the largest negative integer can't be
over 1/2 the range of the unsigned integer, give or take a few.
This means that as long as your test is for a value less than 32K
minus, say, two, you are OK. (Someone else can figure out the
actual limits are, I don't care enough to bother.)

:      Note that I am not looking for the aesthetics of this -- it's
: a trick that will just confuse somebody -- just whether it is portable
: or not.  I know that it works on my machine, which doesn't prove
: much at all.

I've actually found a good use for this trick. On my system, there
is no isascii (because my headers are mostly ANSI) and this is a
real pain sometimes when porting code. This solves that problem:

#define isascii(x) ((unsigned int)(x) <= 255)

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com
From: friedl@mtndew.Tustin.CA.US (Stephen Friedl)
Newsgroups: comp.std.c
Subject: Re: return vs. exit(), ANSI vs. POSIX
Date: 30 Sep 92 14:56:37 GMT
Organization: Steve's Personal machine / Tustin, CA

In the return -vs- exit() question, I thought I'd make a note here.
I have seen quite a few implementations whose startup code did:

	exit(main(argc, argv));

thus making the question moot.

    Stephen

-- 
Stephen J Friedl | Software Consultant | Tustin, CA |     +1 714 544-6561
3b2-kind-of-guy  | I speak for me ONLY |   KA8CMY   | uunet!mtndew!friedl
 
Attorneys are paranoid because they assume everybody else is dishonest too
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: return vs. exit(), ANSI vs. POSIX
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 28 Sep 1992 01:20:45 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,

Yes.  (By the implementation somewhere, not necessarily in the compiler.)

>	              I consider _any_ recursive invocation of main()
>	to be suspect and hence not reasonable.

The standard considers recursive invocation of main() to be allowable and
reasonable.  (Logically reasonable.  The standard does not judge aesthetics.)
RTFS.
--
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: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.std.c
Subject: Re: Re: C-formattors (problems with very long lines)
Date: 1 Oct 1992 10:27:37 +0200
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
NNTP-Posting-Host: daisy.ee.und.ac.za

In article <1992Sep30.092907.28988@olymp.informatik.uni-bonn.de>,
hermann@uran.informatik.uni-bonn.de (Hermann Stamm) writes:
> Below you can find the little prog I am using. It detects both,
> if a ; is inside "..." and inside ' ' . If so, it doesn't insert
> the '\n' after the ; otherwise it does.

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

No.  You also have to worry about preprocessor directives, in which
you would have to use <backslash><newline> instead of just <newline>.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: Change to time() fn?
Date: 29 Sep 92 15:42:52 GMT
Organization: Formerly of Interactive Systems, Cambridge, MA

In article <1992Sep26.153421.7698@cpio1.fr.mugnet.org> bernard@cpio1.fr.mugnet.org (Bernard Fouche) writes:
>[Making |time_t| a |double| could lose accuracy]

True, but if it can exactly represent all the values that a |long int| can,
then it's no worse than what we have now, right?

>[The solution is to use a Bignum library]

Unfortunately, in order to allow for implementations that have no clock, the
Standard requires that |time()| be able to return the constant |(time_t)-1|
to indicate failure.  Hence, |time_t| must be an arithmetic type.

Looks like the original implementation (when |time()| returned its value
*only* through its argument, because |long int| wasn't supported) was on the
right track after all.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.std.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: C-formattors (problems with very long lines)
Organization: TauMetric Corporation
Date: Wed, 30 Sep 1992 16:22:18 GMT

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

>Is there any fixed upper limit for line-length in the 
>ANSI-C-standard ?

Not as such.  A Standard C compiler must handle logical source lines
(after dealing with escaped newlines) of up to 509 characters, and
string literals of up to 509 characters after concatenation.  This
means that you should apply similar limits to source code to
ensure portability.  (A compiler might have no limits on line length,
but it is allowed to have these limits.)


>The more important question I think, is, what is the reason for 
>standard C-beautifiers to break -> in the middle for long lines
>(resulting in a compiler-error).

I would expect that a "standard" C-beautifier would recognize C
tokens, and not split tokens across lines.  I would discard any
"beautifier" that behaves as you describe, since it almost certainly
will create other problems which are not so easy to find.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: order of sequence points in subexpressions
Keywords: sequence points
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Wed, 30 Sep 1992 08:29:46 GMT

In article <1992Sep29.222521.9221@kai.com> david@kai.com (David Nelson) writes:
>[...] what about: "a = b[i+=1,i] + c[i+=1,i];".

The commas introduce sequence points, but they might occur in either order,
or they might even occur simultaneously.  For example, a hypothetical
implementation could order the operations as:
  [previous sequence point]
  i+=1
  i+=1
  , sequence point
  , sequence point
  fetch i
  compute address of c[i] and fetch it
  remember fetched i (or fetch again if volatile; might occur earlier)
  compute address of b[i] and fetch it
  add
  assign to a
  ; sequence point
The two modifications to the stored value between the previous sequence
point and the first sequence point visible here violate this "shall":
>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. 

... and your program might post an "F*** you all" message to alt.pictures.

>My interpretation would be that the sequence point only affects the
>subexpression of the operation that introduced the sequence point.

I think you mean the subexpression[s] that are operand[s] of the operation
that introduced the sequence point -- for example, comma takes two operands.
That would have been a very nice definition (in my personal opinion).
The standard didn't do it that way though.
--
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: phil@ux1.cso.uiuc.edu (Phil Howard)
Subject: Re: this unsigned business
Organization: University of Illinois at Urbana
Date: Fri, 2 Oct 1992 21:07:31 GMT

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"?  I don't have the
standard here, so I am not sure what the official impact is of comparing
an unsigned int and a signed int that happens to be in the positive range.

Maybe it's always OK.  I've never seen any case it isn't.  So would I be
overly paranoid by using "100U" for this?
Newsgroups: comp.std.c