Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #53464 > unrolled thread
| Started by | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| First post | 2014-11-26 21:54 +0100 |
| Last post | 2014-12-19 02:34 +0100 |
| Articles | 17 on this page of 177 — 31 participants |
Back to article view | Back to comp.lang.c
the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:54 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:56 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:45 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:52 +0100
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-01 23:25 -0500
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-02 00:56 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-04 14:52 +0100
Re: the language "Osmium" <r124c4u102@comcast.net> - 2014-12-04 08:07 -0600
Re: the language Geoff <geoff@invalid.invalid> - 2014-12-04 10:20 -0800
Re: the language Mark Storkamp <mstorkamp@yahoo.com> - 2014-11-26 15:11 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:16 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:18 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:12 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-27 00:37 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-27 01:13 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-11-26 22:45 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 07:41 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 08:12 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-27 01:43 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:56 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 09:08 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 20:58 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 19:22 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-02 02:59 +0100
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 02:53 +0000
Re: the language Les Cargill <lcargill99@comcast.com> - 2014-12-01 21:25 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 06:22 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-27 08:37 +0000
Re: the language Reinhardt Behm <rbehm@hushmail.com> - 2014-11-27 16:44 +0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-27 15:35 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-27 11:58 -0500
Re: the language jt@toerring.de (Jens Thoms Toerring) - 2014-11-27 22:44 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 09:52 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 12:53 -0800
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 10:07 +0100
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 14:57 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:09 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:01 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 14:46 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:16 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 22:09 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:40 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 14:42 -0800
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:22 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 23:09 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 16:14 -0800
Re: the language BartC <bc@freeuk.com> - 2014-11-29 01:42 +0000
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-29 01:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 04:03 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-01 00:55 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-02 05:42 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-28 19:25 -0500
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-01 14:02 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-05 10:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 08:25 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 10:44 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 19:17 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 15:48 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 05:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:27 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-08 06:00 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 06:17 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:37 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 12:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 04:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 12:43 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 14:46 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 00:23 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-17 07:01 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 07:22 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-17 11:56 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-17 05:43 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:30 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:41 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 14:34 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 02:15 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-17 22:31 -0500
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:19 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 07:52 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:21 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:15 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 01:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 07:48 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 07:40 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 12:54 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 09:54 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 15:19 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:00 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:13 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:27 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:45 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:48 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 19:10 +0000
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:17 -0600
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:32 -0600
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 16:49 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:00 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:57 -0500
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 14:31 -0800
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 20:29 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 20:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-17 07:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 15:45 +0000
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 16:50 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-17 17:24 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:07 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 12:04 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-18 08:06 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-18 08:30 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 00:11 -0500
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-19 07:00 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-19 08:43 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 23:29 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 00:37 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-20 08:45 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-20 09:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-20 03:17 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-18 06:09 -0800
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:30 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:23 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-18 08:18 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-20 12:22 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-20 13:36 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:43 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:37 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:10 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:02 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-21 22:02 +0000
Re: the language Stephen Sprunk <stephen@sprunk.org> - 2014-12-21 23:49 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-21 17:45 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:29 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-20 05:29 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:32 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:23 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-22 23:39 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:22 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-19 09:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:48 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 02:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 08:31 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 09:31 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 10:10 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 07:08 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-20 06:39 +0000
Re: the language John Forkosh <forkosh@panix.com> - 2014-12-20 07:32 +0000
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 17:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-04 12:40 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 18:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 09:47 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-05 15:14 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-05 08:42 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-06 00:14 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:19 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2015-01-04 15:59 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-04 14:30 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 15:44 -0800
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:36 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:07 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-02 23:16 +0100
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-03 02:23 -0800
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-03 15:55 +0100
Re: the language Nobody <nobody@nowhere.invalid> - 2014-12-03 15:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 04:49 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 09:07 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 10:08 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 11:49 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-05 12:32 +0100
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-04 22:17 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:17 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:12 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:15 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:50 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-19 02:34 +0100
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-01-05 13:36 -0500 |
| Message-ID | <54AAD9A1.8010501@verizon.net> |
| In reply to | #55837 |
On 01/04/2015 03:59 PM, Richard Damon wrote:
> On 1/4/15 12:40 PM, James Kuyper wrote:
...
>> Yes - but allowing such things to happen would also be permitted if the
>> behavior were merely implementation-defined, rather than undefined. The
>> existence of constructs with undefined behavior is not necessary to
>> enable such uses of C.
>>
>
> By the standard, "Implementation Defined Behavior" is behavior where the
> standard put a requirement on the implementation to choose from a small
> list of possible behaviors, and document that decision.
The word "small" is your own addition; the standard itself imposes no
such requirement, and in many cases the list is quite large. For
instance, llrint(LLONG_MAX+1.0 can return any value from LLONG_MIN to
LLONG_MAX (7.12.9.5). In many cases, the list is very open-ended ("The
manner and timing of static initialization", 5.1.2) in which case it's
effectively of infinite length. In the case of non-STDC #pragmas, it's
not clear that there's any possible behavior which isn't on the list).
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-11-28 12:07 +0100 |
| Message-ID | <1plg7ad9h8s6m2kgccnua7vovpkeg8oo5m@4ax.com> |
| In reply to | #53464 |
On 26 Nov 2014 22:28:47 GMT,(Stefan Ram) wrote: >Rosario193 <Rosario@invalid.invalid> writes: >>one language for program has to have no undefinite behaviour >>and has to be simple > > ... e per questo tutti noi usiamo il BASIC. few UB the one depend from hardware... for to be no UB one has to have the same software and hardware
[toc] | [prev] | [next] | [standalone]
| From | "ocq (an evil corporate man)" <ocq@maili.ng> |
|---|---|
| Date | 2014-12-02 23:16 +0100 |
| Message-ID | <m5ldok$sai$1@news.mixmin.net> |
| In reply to | #53464 |
Rosario193 wrote on day 2014‒11‒26: >one language for program has to have no undefinite behaviour >and has to be simple...the one that program has to think to the >problem one want resolve more than language laws etc in the thread there were some examples of defined behaviour called undefined, defined exactly inside the same text where were called undefined. the problem is behaviour: if a programmer writes statement calls instruction of any kind, then he wants to get something defined at once, over anything else is. the problem is programming space: the space is extended when program wants it, when requests it from system; out of this space… next, the standard documents on programming languages (or any other languages) aren՚t made to learn languages, just to implement compilers to be standard compatible. and last, undefined behaviour is not to use because before the behaviour is reached the program has reached an programmer intentions in something written and gone behind it, not before this time some instruction processed has undefined behaviour. undefined behaviour which has defined behaviour on machine a programmer uses, is defined behaviour if has also definied basis of the behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-03 02:23 -0800 |
| Message-ID | <fbd0ee6f-e0ed-4bd5-9390-1cbf44de7e1f@googlegroups.com> |
| In reply to | #53766 |
On Tuesday, December 2, 2014 10:17:00 PM UTC, ocq (an evil corporate man) wrote: > > undefined behaviour which has defined behaviour on machine a programmer > uses, is defined behaviour if has also definied basis of the behaviour. > Undefined behaviour means "undefined by by the C standard", not "existing in some abstract quantum state of undefinability". On most real hardware, the results of UB can easily be determined by someone with a bit of knowledge about the processor's instruction set and how the compiler is likely to treat the code. However C programs with UB aren't correct as C programs. They might be correct if you know that the program is only even going to run with that particular version of the compiler on that particular hardware, or if the compiler declares the UB to be an extension.
[toc] | [prev] | [next] | [standalone]
| From | "ocq (an evil corporate man)" <ocq@maili.ng> |
|---|---|
| Date | 2014-12-03 15:55 +0100 |
| Message-ID | <m5n88m$ibr$1@news.mixmin.net> |
| In reply to | #53776 |
Malcolm McLean wrote on day 2014‒12‒3: >On Tuesday, December 2, 2014 10:17:00 PM UTC, ocq (an evil corporate man) wrote: >> >> undefined behaviour which has defined behaviour on machine a programmer >> uses, is defined behaviour if has also definied basis of the behaviour. >> >Undefined behaviour means "undefined by by the C standard", not "existing in >some abstract quantum state of undefinability". On most real hardware, the >results of UB can easily be determined by someone with a bit of knowledge >about the processor's instruction set and how the compiler is likely to treat >the code. >However C programs with UB aren't correct as C programs. They might be >correct if you know that the program is only even going to run with that >particular version of the compiler on that particular hardware, or if the >compiler declares the UB to be an extension. that՚s a situation, common one, when (first) undefined behaviour that has happen, results in undefined behaviour which is defined by user and next maybe programmer— as behaviour strictly. however after the first undefined behaviour of some instruction in the program, there is any set of results of instructions and some one of them is visible as undefined behaviour, really the set of behaviour (invisible or not) at all is undefined, maybe stable temporary. above I did never think about such a set of undefined behaviour is visible as program is not doing something or fails in how it is doing something. I wrote about undefined behaviour of first instruction that a programmer can know which it is, not an user. C standard says about rather such undefined behaviour. and this undefined behaviour could be defined for some target machine because some definition is open and can be defined as an instruction, and not because there is some trick inside a compiler (which however would be incompatible with the standard). the hardware is the basis, not language, where is everything what is used going by programming language, as program of use.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.invalid> |
|---|---|
| Date | 2014-12-03 15:42 +0000 |
| Message-ID | <pan.2014.12.03.15.42.24.662000@nowhere.invalid> |
| In reply to | #53776 |
On Wed, 03 Dec 2014 02:23:14 -0800, Malcolm McLean wrote: >> undefined behaviour which has defined behaviour on machine a programmer >> uses, is defined behaviour if has also definied basis of the behaviour. >> > Undefined behaviour means "undefined by by the C standard", not "existing > in some abstract quantum state of undefinability". On most real hardware, > the results of UB can easily be determined by someone with a bit of > knowledge about the processor's instruction set and how the compiler is > likely to treat the code. Knowledge about the hardware is less relevant than knowledge of the compiler's internals. And unlike the former, the latter changes with each new version of the compiler. When optimisation is enabled, modern compilers are sufficiently complex that anyone who thinks that they understand how the compiler is likely to treat the code is almost certainly wrong. Even the people who wrote the compiler probably can't reliably predict how it will actually compile anything beyond the most trivial expression. UB is no longer about simply getting the implementation-specific behaviour of whatever instructions arise from a mechanical translation of C expressions to assembler. Modern compilers will specifically identify the bounds of defined behaviour and use those in optimising the code. Signed arithmetic will be assumed not to overflow. Any expression used as the second operand to / or % will be assumed to be non-zero (and not just within the / or % operation itself).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-04 04:49 -0800 |
| Message-ID | <40a60afd-35ee-4bfd-900b-f308d53363a5@googlegroups.com> |
| In reply to | #53801 |
On Wednesday, December 3, 2014 3:42:06 PM UTC, Nobody wrote: > > Modern compilers will specifically identify the bounds of defined > behaviour and use those in optimising the code. Signed arithmetic will be > assumed not to overflow. Any expression used as the second operand to / or > % will be assumed to be non-zero (and not just within the / or % operation > itself). > So that gives you two examples where you can tell what the UB will be.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-04 09:07 -0800 |
| Message-ID | <ln61drpcma.fsf@nuthaus.mib.org> |
| In reply to | #53874 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, December 3, 2014 3:42:06 PM UTC, Nobody wrote:
>> Modern compilers will specifically identify the bounds of defined
>> behaviour and use those in optimising the code. Signed arithmetic will be
>> assumed not to overflow. Any expression used as the second operand to / or
>> % will be assumed to be non-zero (and not just within the / or % operation
>> itself).
>>
> So that gives you two examples where you can tell what the UB will be.
Not really. Given:
x = y / z;
a compiler may *assume* that z!=0. There are a wide variety of things
it can do based on that assumption.
--
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 | 2014-12-04 10:08 -0800 |
| Message-ID | <dc89145c-85ef-45fb-b3fc-74891da58063@googlegroups.com> |
| In reply to | #53897 |
On Thursday, December 4, 2014 5:07:49 PM UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > On Wednesday, December 3, 2014 3:42:06 PM UTC, Nobody wrote: > >> Modern compilers will specifically identify the bounds of defined > >> behaviour and use those in optimising the code. Signed arithmetic will be > >> assumed not to overflow. Any expression used as the second operand to / or > >> % will be assumed to be non-zero (and not just within the / or % operation > >> itself). > >> > > So that gives you two examples where you can tell what the UB will be. > > Not really. Given: > > x = y / z; > > a compiler may *assume* that z!=0. There are a wide variety of things > it can do based on that assumption. > Assuming it can't optimise out the calculation, it's going to do one of two things. Either issue the machine instruction divide register 1 by register 2 (set to zero), or issue the machine instruction take the reciprocal of register 2, followed by a multiply. The machine will have defined error behaviour for divide by zero in these two case, which is probably the same behaviour for both dividing and taking a reciprocal. (There might be special instructions for setting the divide by zero error handler, so then obviously you've got to know).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-04 11:49 -0800 |
| Message-ID | <lnwq67nqke.fsf@nuthaus.mib.org> |
| In reply to | #53898 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, December 4, 2014 5:07:49 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Wednesday, December 3, 2014 3:42:06 PM UTC, Nobody wrote:
>> >> Modern compilers will specifically identify the bounds of defined
>> >> behaviour and use those in optimising the code. Signed arithmetic will be
>> >> assumed not to overflow. Any expression used as the second operand to / or
>> >> % will be assumed to be non-zero (and not just within the / or % operation
>> >> itself).
>> >>
>> > So that gives you two examples where you can tell what the UB will be.
>>
>> Not really. Given:
>>
>> x = y / z;
>>
>> a compiler may *assume* that z!=0. There are a wide variety of things
>> it can do based on that assumption.
>>
> Assuming it can't optimise out the calculation, it's going to do one of two
> things. Either issue the machine instruction divide register 1 by register 2
> (set to zero), or issue the machine instruction take the reciprocal of
> register 2, followed by a multiply.
> The machine will have defined error behaviour for divide by zero in these
> two case, which is probably the same behaviour for both dividing and taking
> a reciprocal.
> (There might be special instructions for setting the divide by zero error
> handler, so then obviously you've got to know).
The assumption that z!=0 doesn't *just* apply to the division.
For example, an optimizing compiler might generate exactly the same code
for these two programs:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(void) {
srand(time(NULL));
int x;
int y = 1;
int z = rand();
x = y / z;
printf("z is %s to zero\n", z == 0 ? "equal" : "not equal");
}
and
#include <stdio.h>
int main(void) {
puts("z is not equal to zero");
}
If z is unequal to zero, the two programs clearly have the same
behavior. If z is equal to zero, the behavior of the first program
is undefined; printing "z is unequal to zero" is as valid as any
other behavior. In either case, the result of the division is
never used, so the division needn't be performed.
--
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 | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-12-05 12:32 +0100 |
| Message-ID | <2o538a1l0hr818eb1oi0umgke4rf188mbb@4ax.com> |
| In reply to | #53902 |
On Thu, 04 Dec 2014 11:49:21 -0800, Keith Thompson wrote:
>Malcolm McLean writes:
>> On Thursday, December 4, 2014 5:07:49 PM UTC, Keith Thompson wrote:
>>> Malcolm McLean writes:
>>> > On Wednesday, December 3, 2014 3:42:06 PM UTC, Nobody wrote:
>>> >> Modern compilers will specifically identify the bounds of defined
>>> >> behaviour and use those in optimising the code. Signed arithmetic will be
>>> >> assumed not to overflow. Any expression used as the second operand to / or
>>> >> % will be assumed to be non-zero (and not just within the / or % operation
>>> >> itself).
>>> >>
>>> > So that gives you two examples where you can tell what the UB will be.
>>>
>>> Not really. Given:
>>>
>>> x = y / z;
>>>
>>> a compiler may *assume* that z!=0. There are a wide variety of things
>>> it can do based on that assumption.
it can assume that because doing y/0.0 is one error for the
programmer that in his code allow that
>> Assuming it can't optimise out the calculation, it's going to do one of two
>> things. Either issue the machine instruction divide register 1 by register 2
>> (set to zero), or issue the machine instruction take the reciprocal of
>> register 2, followed by a multiply.
>> The machine will have defined error behaviour for divide by zero in these
>> two case, which is probably the same behaviour for both dividing and taking
>> a reciprocal.
>> (There might be special instructions for setting the divide by zero error
>> handler, so then obviously you've got to know).
>
>The assumption that z!=0 doesn't *just* apply to the division.
>
>For example, an optimizing compiler might generate exactly the same code
>for these two programs:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
> int main(void) {
> srand(time(NULL));
> int x;
> int y = 1;
> int z = rand();
> x = y / z;
> printf("z is %s to zero\n", z == 0 ? "equal" : "not equal");
> }
>
>and
>
> #include <stdio.h>
> int main(void) {
> puts("z is not equal to zero");
> }
>
>If z is unequal to zero, the two programs clearly have the same
>behavior. If z is equal to zero, the behavior of the first program
>is undefined; printing "z is unequal to zero" is as valid as any
>other behavior. In either case, the result of the division is
>never used, so the division needn't be performed.
first to be UB, y/z where z=0.0 is one programmer error...
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-04 22:17 +0000 |
| Message-ID | <5480dd62.6768937@news.xs4all.nl> |
| In reply to | #53874 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Wednesday, December 3, 2014 3:42:06 PM UTC, Nobody wrote: > > > > Modern compilers will specifically identify the bounds of defined > > behaviour and use those in optimising the code. Signed arithmetic will be > > assumed not to overflow. Any expression used as the second operand to / or > > % will be assumed to be non-zero (and not just within the / or % operation > > itself). > > > So that gives you two examples where you can tell what the UB will be. Nope, it gives you two examples where you can tell what the undefined behaviour _probably_ will be. Good luck relying on that "probably" for your pacemaker, buddy. Richard
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-12-18 18:17 +0100 |
| Message-ID | <5n269ahn7kfv6g7cb9gd0gtt90u1rn2nlr@4ax.com> |
| In reply to | #53464 |
On Wed, 26 Nov 2014 21:54:56 +0100, Rosario193 <Rosario@invalid.invalid> wrote: >one language for program has to have no undefinite behaviour >and has to be simple...the one that program has to think to the >problem one want resolve more than language laws etc it seems that someone argued about the impossible to have a language without UBs... the x86 assembly has each instruction [without only RDTSC instruction] one know what contain first operand, what contain second operad etc than instruction(operand1, operand2 etc) is definited whithout UBs...
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-18 18:12 +0000 |
| Message-ID | <IOEkw.189390$RM2.31252@fx43.am4> |
| In reply to | #54968 |
Rosario193 wrote: > On Wed, 26 Nov 2014 21:54:56 +0100, Rosario193 > <Rosario@invalid.invalid> wrote: > >>one language for program has to have no undefinite behaviour >>and has to be simple...the one that program has to think to the >>problem one want resolve more than language laws etc > > it seems that someone argued about the impossible to have a language > without UBs... They did? I don't recall that. Surely it's trivial (as far as language design can ever be considered trivial) to design a closed-in language in which every possible behaviour is defined? > > the x86 assembly > has each instruction [without only RDTSC instruction] > one know what contain first operand, > what contain second operad etc > than instruction(operand1, operand2 etc) > is definited > whithout UBs... And how are you going to run that program on, say, VM/CMS? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-12-18 23:15 +0100 |
| Message-ID | <v7k69a1dgucgco5d6cn60rdllmjh33fiea@4ax.com> |
| In reply to | #54980 |
On Thu, 18 Dec 2014 18:12:55 +0000, Richard Heathfield <invalid@see.sig.invalid> wrote: >Rosario193 wrote: > >> On Wed, 26 Nov 2014 21:54:56 +0100, Rosario193 >> <Rosario@invalid.invalid> wrote: >> >>>one language for program has to have no undefinite behaviour >>>and has to be simple...the one that program has to think to the >>>problem one want resolve more than language laws etc >> >> it seems that someone argued about the impossible to have a language >> without UBs... > >They did? I don't recall that. Surely it's trivial (as far as language >design can ever be considered trivial) to design a closed-in language in >which every possible behaviour is defined? > >> >> the x86 assembly >> has each instruction [without only RDTSC instruction] >> one know what contain first operand, >> what contain second operad etc >> than instruction(operand1, operand2 etc) >> is definited >> whithout UBs... > >And how are you going to run that program on, say, VM/CMS? first of doing one cpu one OS one language people has to be agreee what are mathematical function or mathematical operation +: u8 x u8 -> u8 it is not possible in a sys 256 + 256 = 0 and in anhother sys 256+256=1 all in a 0..256 8 bit varible
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-12-18 23:50 +0100 |
| Message-ID | <bam69ath8hic110mfdidj7t9nvp0lj1vnq@4ax.com> |
| In reply to | #55009 |
On Thu, 18 Dec 2014 23:15:05 +0100, Rosario193 wrote: >first of doing one cpu one OS one language > >people has to be agreee what are mathematical function >or mathematical operation > >+: u8 x u8 -> u8 > >it is not possible in a sys 256 + 256 = 0 and in anhother sys >256+256=1 all in a 0..256 8 bit varible unsigned char a=255, b=255, c; c=a+b; where unsigned char is one unsigned 8 bit it is not possible in a sys c=0 and in one other sys c=1 etc
[toc] | [prev] | [next] | [standalone]
| From | "ocq (an evil corporate man)" <ocq@maili.ng> |
|---|---|
| Date | 2014-12-19 02:34 +0100 |
| Message-ID | <m6vvaa$947$1@news.mixmin.net> |
| In reply to | #54968 |
Rosario193 wrote on day 2014‒12‒18: >it seems that someone argued about the impossible to have a language >without UBs... why not… it depends on actions. this is a language. some, not computer programming one. everybody who reads it, understands it what he has in the place on. so we are talking about C programming language to know what everybody has in the place to do on. however thare are several compilers are not compatible. so if someone writing knows what is in the place different to handle the behaviour or requires to handle the behaviour he wants from everybody thinking and interpreting the language written. the last is possible and it costs. it՚s price of allocating resources for every case is possible to use by writer who is free upto the standard of the language, not upto the place. >the x86 assembly >has each instruction [without only RDTSC instruction] >one know what contain first operand, >what contain second operad etc >than instruction(operand1, operand2 etc) >is definited >whithout UBs... some instructions do more than math operand does.
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web