Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #83803 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-03-13 12:52 -0700 |
| Last post | 2016-03-14 09:33 -0700 |
| Articles | 16 on this page of 96 — 17 participants |
Back to article view | Back to comp.lang.c
c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 12:52 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 13:05 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 13:25 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 16:28 -0700
Re: c is unfinished Les Cargill <lcargill99@comcast.com> - 2016-03-13 15:20 -0500
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 13:15 -0700
Re: c is unfinished Les Cargill <lcargill99@comcast.com> - 2016-03-14 07:27 -0500
Re: c is unfinished gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-14 12:47 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 06:50 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:04 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 07:23 -0700
c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-13 14:17 -0700
Re: c is unfinished "John M. Harris, Jr." <johnmh@openblox.org> - 2016-03-14 08:57 -0400
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 07:06 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:23 -0700
Re: c is unfinished "John M. Harris, Jr." <johnmh@openblox.org> - 2016-03-14 10:28 -0400
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 08:06 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 15:26 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 08:38 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 09:15 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 09:42 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 16:23 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 09:56 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 10:03 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 17:28 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 11:08 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 18:51 +0000
Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:10 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 16:26 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 23:55 +0000
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 22:44 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 08:59 +0100
Re: c is unfinished supercat@casperkitty.com - 2016-03-15 07:23 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 15:31 +0100
Re: c is unfinished supercat@casperkitty.com - 2016-03-15 08:02 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:11 +0100
Re: c is unfinished supercat@casperkitty.com - 2016-03-16 08:33 -0700
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 09:40 +1300
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 14:01 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 15:33 -0700
Re: c is unfinished gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-14 23:07 +0000
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 16:27 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:37 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 21:07 +0000
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 10:16 +1300
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 22:05 +0000
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 15:30 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 15:39 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 23:00 +0000
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 18:09 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 08:14 +0000
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-15 13:51 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 10:01 +0100
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-15 17:07 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:26 +0100
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-16 13:28 -0700
Re: c is unfinished Philip Lantz <prl@canterey.us> - 2016-03-15 20:03 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:52 +0100
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-16 20:39 +1300
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 09:14 +0100
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-16 22:40 +1300
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 12:46 +0100
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 14:53 +1300
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 08:17 +0000
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 21:19 +1300
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 15:16 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:03 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 08:32 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 08:43 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 16:14 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 10:01 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 17:30 +0000
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 10:57 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 11:32 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 12:12 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 19:21 +0000
Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:16 +0000
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 15:34 -0700
Re: c is unfinished Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 20:15 -0500
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 22:05 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 22:34 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 16:17 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-15 01:10 +0000
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 12:03 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 19:08 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 13:01 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 13:28 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 14:25 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 14:40 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 14:44 -0700
Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:44 +0000
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:26 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:09 -0700
Re: c is unfinished Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2016-03-13 23:34 +0000
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 16:40 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 09:33 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-14 22:34 -0700 |
| Message-ID | <lnio0oi9sn.fsf@kst-u.example.com> |
| In reply to | #83978 |
supercat@casperkitty.com writes:
> On Monday, March 14, 2016 at 8:14:33 PM UTC-5, robert...@yahoo.com wrote:
>> Unsigned postdates the 6th Edition Unix (May 1975) implementation of
>> C:
>> https://www.bell-labs.com/usr/dmr/www/cman.pdf
>
> That manual must come from the same alternate universe that Malcolm and I
> come from.
The claim is that some early version of malloc() took an int argument.
That manual doesn't mention malloc().
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-03-14 16:17 -0700 |
| Message-ID | <a04a1e13-a80d-49a9-993f-c66598380cdd@googlegroups.com> |
| In reply to | #83946 |
On Monday, March 14, 2016 at 10:17:33 PM UTC, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > On Monday, March 14, 2016 at 5:57:27 PM UTC, Keith Thompson wrote: > > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > > > > On what planet does malloc() take a signed value? > > > > > Once upon a time it took an int. > > Are you living in the supercat alternative universe now? > > I have a very old, very idiosyncratic Dutch AT&T C manual in which > malloc() takes an _unsigned_ int. I have never seen one which took a > signed one. > I checked an old compiler. Of course there are no prototypes. You just pass whatever happens to be pushed on the stack to the function. So it's moot whether the integer was signed or unsigned, given that a large allocation request would fail because there wasn't that much memory in the machine.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-03-15 01:10 +0000 |
| Message-ID | <878u1k35ry.fsf@bsb.me.uk> |
| In reply to | #83959 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, March 14, 2016 at 10:17:33 PM UTC, Richard Bos wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >> >> > On Monday, March 14, 2016 at 5:57:27 PM UTC, Keith Thompson wrote: >> > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > > >> > > On what planet does malloc() take a signed value? >> > > >> > Once upon a time it took an int. >> >> Are you living in the supercat alternative universe now? >> >> I have a very old, very idiosyncratic Dutch AT&T C manual in which >> malloc() takes an _unsigned_ int. I have never seen one which took a >> signed one. >> > I checked an old compiler. > Of course there are no prototypes. You just pass whatever happens > to be pushed on the stack to the function. So it's moot whether > the integer was signed or unsigned, given that a large allocation > request would fail because there wasn't that much memory in the > machine. No, it's not moot. The size is unsigned no matter what you pass, and the programmer needed to know that then as now. That is the purpose of giving the type in the manual page. And what do you mean by large allocations? There were machines at that time with a 16-bit int yet which permitted permit 64k bytes of code and 64k bytes of data. That extra bit mattered more then than now. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-03-14 12:03 -0700 |
| Message-ID | <da424949-aac0-45f1-927c-4f0e4b4ea0ea@googlegroups.com> |
| In reply to | #83896 |
On Monday, March 14, 2016 at 12:57:27 PM UTC-5, Keith Thompson wrote: > Of course. But if you arbitrarily correct C's "glitches" one at a > time as they pop up, the end result is not likely to be a coherent > language. It's more likely to be, not C++, but something like what > C++'s detractors claim it to be. More likely, one would end up with something resembling the collection of microprocessor C dialects that were used throughout the 1990s which extended the C Standard in ways which weren't always 100% consistent, but shared enough of a common core that it was practical to write code which would meet requirements when run on any "normal" C compiler even though it relied upon behaviors for which the Standard imposed no requirements. The C Standards were written at a time when compilers had largely converged on a common language, but with a few important differences (such as whether smaller unsigned types should promote to larger signed types or unsigned types). They were not designed to be micro-analyzed in the fashion that has since become fashionable. If a particular optimization would break lots of existing code, it didn't matter whether the Standard said it was allowed-- the marketplace would reject as "abnormal" compilers that tried to apply it without being told to do so. The deficiencies in the Standard didn't really matter when compiler writers didn't try to use them to justify code-breaking "optimizations", but as compilers become more and more aggressive the deficiencies become more and more grave. Unfortunately, unless someone has enough political cloud to have recognized as "normative" behaviors which were supported for decades and allowed programs to be more efficient, but which it has since become more fashionable to break, I don't see any way to avoid a major fissure between those who cling to the Standard and those who are more interested in the well-established behavioral norms.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-03-14 19:08 +0000 |
| Message-ID | <87bn6g513y.fsf@bsb.me.uk> |
| In reply to | #83892 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, March 14, 2016 at 4:14:37 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Monday, March 14, 2016 at 2:28:38 PM UTC, John M. Harris, Jr. wrote:
>> >>
>> >> What's a "try"? What's a "catch"? In C, you don't need to worry about
>> >> that silly stuff,
>>
>> <snip>
>> > IMAGE *createimage(int width, int height)
>> > {
>> > IMAGE *answer;
>> >
>> > answer = malloc(sizeof((MAGE));
>> > answer->rgba = malloc(width * height * 4);
>> > answer->width = width;
>> > answer->height = height;
>> > meset(answer->rgba, 0, width*height*4);
>> > return answer;
>> > }
>> >
>> > pretty unexceptional (pun), routine code.
>> >
>> > But of course it's wrong. It doesn't handle out of memory errors,
>> > and, more insidiously, it doesn't handle width * height > INT_MAX.
>>
>> Even more insidiously it does not handle width * height > INT_MAX/4 nor
>> width * height * 4 > SIZE_MAX (though this is unlikely).
>>
>> > (Quick question, what happens if we make the image dimensions size_t?)
>> >
>> > try catch together with automatic cleanup allows us to write the code
>> > exactly like that, in the natural way, and have correct behaviour on
>> > malicious input (and image dimensions is something that could well be
>> > derived from user input).
>>
>> Even assuming (from other posts) that signed integer overflow raises an
>> exception, how would try/catch help with createimage(-10, 10)? And are
>> you assuming that ((IMAGE *)0)->rgba will raise an exception? And what
>> about width * height * 4 > SIZE_MAX?
>>
> We call malloc with -400. Since malloc() takes a signed value, that is constrained
> to throw an exception, which we handle.
Nope, malloc takes size_t.
> Of course -10, -10 will be a bit problematic, you could argue that such an
> image should have area (I'll leave the mathematicians to rule on that one).
>
> I am of course assuming a superior try .. catch C with some of the glitches
> taken out.
What about the other point? How does try/catch help with them?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-03-14 13:01 -0700 |
| Message-ID | <cb601626-bbf7-4e26-9e2b-deded93efd75@googlegroups.com> |
| In reply to | #83910 |
On Monday, March 14, 2016 at 7:08:28 PM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > We call malloc with -400. Since malloc() takes a signed value, > > that is constrained to throw an exception, which we handle. > > Nope, malloc takes size_t. > > > Of course -10, -10 will be a bit problematic, you could argue > > that such an image should have area (I'll leave the mathematicians > > to rule on that one). > > > > I am of course assuming a superior try .. catch C with some of > > the glitches taken out. > > What about the other point? How does try/catch help with them? > If we're going to add arithmetical overflow error exception throwing to C, then of course you mustn't pass about amounts of memory or index values in unsigned integers, or, alternatively, you could alter the C standard to specify that unsigned arithmetic has undefined behaviour on overflow. The last has implications for some legitimate low-level techniques, so the obvious answer is to deprecate size_t. It needs one tweak to the core C standard, and a minor change to the standard library.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-03-14 13:28 -0700 |
| Message-ID | <0649ba00-e977-47cc-8e86-597e775f89ca@googlegroups.com> |
| In reply to | #83915 |
On Monday, March 14, 2016 at 3:01:34 PM UTC-5, Malcolm McLean wrote: > .... The last has implications > for some legitimate low-level techniques, so the obvious answer is > to deprecate size_t. > It needs one tweak to the core C standard, and a minor change to > the standard library. Whether or not size_t exists as an identifier, the "sizeof" operator has to yield a value of some type, and it's possible that code might assume that an expression like "sizeof (someType) - 24 <= 16" may be used to test whether an object's size is between 24 and 40 bytes, inclusive. I don't see any way to allow a compiler to add automatic overflow checks to expressions involving sizeof without breaking compatibility with at least some code that uses sizeof in ways whose behavior is fully defined by the present Standard. What may be helpful, however, would be to define multiple forms of unsigned integer, with differing semantics, in such a way that most code which was likely to break as a result of such issues would yield compile-time diagnostics [e.g. it could have a "quasi-unsigned" type which behaves as unsigned, but generates warnings in cases where it would have defined behaviors which would differ from those of signed types]. Of all the ways a later version of a language might be incompatible with its predecessor, I'd say the least problematic are those where code will either work the same as with the preceding version or will generate a compiler diagnostic; that's far less of a problem than cases where code whose behavior is well-defined in an earlier version of a language will invoke Undefined Behavior in a later version but not invoke any diagnostic--something which can happen in many subtle ways if C89 code is compiled in C99 [such code may fail on later versions of gcc even in c89 mode, but that's because gcc has ceased to be C89-compliant, not because the code wasn't defined in C89].
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-14 14:25 -0700 |
| Message-ID | <lnoaagkb08.fsf@kst-u.example.com> |
| In reply to | #83915 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, March 14, 2016 at 7:08:28 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > We call malloc with -400. Since malloc() takes a signed value,
>> > that is constrained to throw an exception, which we handle.
>>
>> Nope, malloc takes size_t.
>>
>> > Of course -10, -10 will be a bit problematic, you could argue
>> > that such an image should have area (I'll leave the mathematicians
>> > to rule on that one).
>> >
>> > I am of course assuming a superior try .. catch C with some of
>> > the glitches taken out.
>>
>> What about the other point? How does try/catch help with them?
>>
> If we're going to add arithmetical overflow error exception
> throwing to C, then of course you mustn't pass about amounts
> of memory or index values in unsigned integers, or, alternatively,
> you could alter the C standard to specify that unsigned arithmetic
> has undefined behaviour on overflow.
That doesn't demonstrate an understanding of what "undefined behavior"
means.
What I think you're suggesting is that the behavior on overflow of a
size_t*size_t multiplication would be *defined* to throw an exception.
(If you merely want to leave it undefined and allow it to throw an
exception, then it's of no use to portable code.)
> The last has implications
> for some legitimate low-level techniques, so the obvious answer is
> to deprecate size_t.
Yeah, that's not going to happen.
> It needs one tweak to the core C standard, and a minor change to
> the standard library.
I presume you'd want malloc() to take an int argument? Presumably
sizeof would also yield int rather than size_t. If so, that would
impose an additional constraint on all hosted implementations: that the
range of int must be wide enough to represent the size of any object.
Or you could require size_t to be *some* chosen signed type, not
necessarily int -- but that would mean 32-bit systems couldn't have
objects bigger than 2GB. (I'm not sure whether that's an issue in
practice.) That's basically what the POSIX type ssize_t is.
If we're going to add exceptions to C *and* (unlike C++) specify that
numeric overflow throws an exception, then a more reasonable approach
would be to define a new kind of integer type, similar to current
unsigned types except that overflow throws an exception rather than
wrapping. size_t then could be a typedef for one of these types. But
that would break existing code that uses `(size_t)-1` to denote
`SIZE_MAX` (which wasn't defined until C99).
And of course requiring integer overflow to be detected would hurt
performance.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-03-14 14:40 -0700 |
| Message-ID | <73f9765d-53c1-4626-a04b-0c8995caf2da@googlegroups.com> |
| In reply to | #83929 |
On Monday, March 14, 2016 at 4:25:35 PM UTC-5, Keith Thompson wrote:
> And of course requiring integer overflow to be detected would hurt
> performance.
Use of a type which was required to detect overflow would hurt performance
compared with having code be oblivious to the possibility of overflow, but
would hurt performance far less than having user code explicitly check for
overflow at every point where it might occur, especially if the compiler
were allowed to arbitrarily detect or not any overflow which would not affect
the numerical correctness of the final result.
For example, suppose one needs a function with the following characteristics:
int sum(int dat[], int n);
/* Compute the sum of n items in array dat[], subject to the following
constraints:
1. If no partial sum from adding the items sequentially exceeds the
range of "int", return the arithmetically-correct sum and do not
modify errno.
2. If the arithmetically-correct value of the sum is not representable
as "int", return any value and set errno to [some value].
3. If some partial sums would exceed the range of "int" but the final
result would not, arbitrarily select between #1 or #2 above.
*/
I would suggest that there are a lot of places where it's important that the
program must either report an arithmetically-correct sum or report an error,
but where either behavior would be acceptable if an overflow would occur
but the function would produce the arithmetically-correct result anyway. On
some systems, performing extended-precision arithmetic and checking whether
the final result fit in "int" would be cheaper than performing overflow
checking at every stage. On others the reverse would be true. On others,
the relative cost may vary depending upon context. Letting the compiler pick
whichever approach is best would likely yield better code than forcing the
programmer to pick.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-03-14 14:44 -0700 |
| Message-ID | <f59baada-6cfb-48ff-95e5-2eaf06e8ffa8@googlegroups.com> |
| In reply to | #83929 |
On Monday, March 14, 2016 at 9:25:35 PM UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > If we're going to add arithmetical overflow error exception > > throwing to C, then of course you mustn't pass about amounts > > of memory or index values in unsigned integers, or, alternatively, > > you could alter the C standard to specify that unsigned arithmetic > > has undefined behaviour on overflow. > > That doesn't demonstrate an understanding of what "undefined behavior" > means. > > What I think you're suggesting is that the behavior on overflow of a > size_t*size_t multiplication would be *defined* to throw an exception. > (If you merely want to leave it undefined and allow it to throw an > exception, then it's of no use to portable code.) > You're right. You need to have guarantee that the exception will be thrown and, if appropriate, caught. So code no longer has undefined behaviour on overflow. However it is backwards-compatible with compliant C where the overflow behaviour was undefined. > > I presume you'd want malloc() to take an int argument? Presumably > sizeof would also yield int rather than size_t. If so, that would > impose an additional constraint on all hosted implementations: that the > range of int must be wide enough to represent the size of any object. > Yes, so we need to go to 64 bit ints.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-03-14 22:44 +0000 |
| Message-ID | <56e73e6b.3935281@news.xs4all.nl> |
| In reply to | #83933 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, March 14, 2016 at 9:25:35 PM UTC, Keith Thompson wrote: > > > > I presume you'd want malloc() to take an int argument? Presumably > > sizeof would also yield int rather than size_t. If so, that would > > impose an additional constraint on all hosted implementations: that the > > range of int must be wide enough to represent the size of any object. > > > Yes, so we need to go to 64 bit ints. Since when is that good enough? Ever since the Big Crunch was replaced with the Big Rip, we've stopped working in gigayear cosmology and switched to terayears, so we need _at least_ 256-bit ints for our simulations. And so it progresses. Until you get the bat out of your belfry that "one size fits all". Richard
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-03-14 19:26 -0700 |
| Message-ID | <9d109f4c-2362-4bb4-9808-dbfc4f4f76f7@googlegroups.com> |
| In reply to | #83933 |
W dniu poniedziałek, 14 marca 2016 22:45:08 UTC+1 użytkownik Malcolm McLean napisał: > > > Yes, so we need to go to 64 bit ints. 64 bit ints are probably slower, at least in some cases (say 'half' ;-0 ) its like with double, from some time i think double is rarely usefull, i just never use it (except one case of timer as i em not accustomed to make int64 arithmetic on win32 feel better to jus cast it to double ;-) this is becouse that in efficient programs speed ~ bandwidth and doubles take 2x bandwidth, int64 takes 2x bandwidth - which may make game running 40 fps instead of 60 thats why i think that short float could be usefull as it is often provided and used on gpu, same with shorts for some arrays storage where your array will just be twice smaller like 5MB instead of 10MB and thus almost twice faster (in the cases when you can use it) so its worth remembering imo int64 is slower (and at least check if its the case)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-03-14 07:09 -0700 |
| Message-ID | <9db62dce-b7c8-4d3a-a139-b8aba63a5f3d@googlegroups.com> |
| In reply to | #83872 |
Always remember:
https://www.youtube.com/watch?v=H4YRPdRXKFs
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> |
|---|---|
| Date | 2016-03-13 23:34 +0000 |
| Message-ID | <nc4tdt$1ob$1@news.albasani.net> |
| In reply to | #83803 |
On Sun, 13 Mar 2016 12:52:28 -0700, fir wrote: > this is some thetis of my: c is unfinished You are right - will never be finished, no matter how many times we are told it is.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-03-13 16:40 -0700 |
| Message-ID | <77b677d2-ed6e-43a6-afad-1cef4799411b@googlegroups.com> |
| In reply to | #83830 |
W dniu poniedziałek, 14 marca 2016 00:34:35 UTC+1 użytkownik Jens Stuckelberger napisał: > On Sun, 13 Mar 2016 12:52:28 -0700, fir wrote: > > > this is some thetis of my: c is unfinished > > You are right - will never be finished, no matter how many times > we are told it is. as to this i am not sure
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-03-14 09:33 -0700 |
| Message-ID | <77d655a3-e42b-425e-bfbc-5b5009c3e7ff@googlegroups.com> |
| In reply to | #83803 |
On Sunday, March 13, 2016 at 2:52:45 PM UTC-5, fir wrote: > this is some thetis of my: c is unfinished Certain aspects of the language are poorly specified. This didn't pose a problem in the days when compiler writers were more interested in compatibility with code written for other compilers than in what the Standard would allow them to do (bearing in mind that C became popular before there even *was* a standard), but poses an increasing problem in the days of increasingly-aggressive optimization. No version of the C Standard makes much mention of the fact that a C implementation runs code on some kind of processor, or that processors have various "natural" behaviors in various situations. For most forms of "Undefined Behavior", the most natural specification would be "choose in arbitrary fashion from one or more behaviors listed in the Standard, or any behavior that would be "natural" on the underlying platform", but since the requirements don't recognize the existence of an underlying platform, and since the authors saw no reason why a compiler would do anything else, they made no distinction among different kinds of Undefined Behavior. There are many kinds of operation for which a compiler would be able to yield code which will meet behavioral requirements 100% of the time if as long as it *doesn't* know certain things, but where knowledge of certain things may cause the compiler to interpret the code in a fashion which complies with the C Standard but no longer meets requirements. Modern compiler philosophy pushes the revisionist view that such code was never legitimate. I would posit that the problem is instead the Standard's failure to acknowledge the existence of useful behaviors which were common to 99% of compilers in existence.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web