Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #67863

Re: the language (and the role of Undefined Behavior therein)

Show all headers | View raw

On 08/19/2015 07:01 PM, supercat@casperkitty.com wrote:
> On Wednesday, August 19, 2015 at 3:10:58 PM UTC-5, James Kuyper wrote:
>> What is both permitted by the standard, and unambiguously possible in
>> the real world, is that as soon as the code reaches a point where a
>> value of 33 is the only way to avoid undefined behavior, the program can
>> start executing code that does pretty much anything, if the value isn't
>> 33.
> 
> I'd say such behavior effectively frees the abstract machine from
> the laws of time and causality. Normal rules of time and causality would
> imply that "if (foo==23) bar();" may only execute "bar()" if the program
> receives input which could, for some combination of specified and
> unspecified behaviors that could have occurred up to that point, cause
> "foo" to equal 23. On some compilers, Undefined Behavior negates those
> rules.

Well, the actual laws of time and causality are not written in such a
way as to allow you to justify that conclusion. They require only that a
cause of an effect be separated from the effect it causes by an amount
of time greater than the time required for light to travel from the
location of the cause to the location of the effect. In particular, the
way I worded that implies that the time must be positive. The ultimate
cause of the execution of bar() is the fact that the compiler performed
the optimization, which occurs long before the effect; light has plenty
of time to travel from the location where the optimization was performed
to the location where the optimized code was executed.

The laws of time and causality don't say that foo==32 has to cause bar()
to be executed - it's the C standard which says that; and it only says
it in contexts where the behavior is defined. When the behavior is
undefined, the standard revokes that requirement, so a compiler can
generate code (which behaves strictly according to the laws of time and
causality) to produce a result quite different from that one.

> I agree that the present standard as written allows such an
> optimization; I would posit, however, that the inability for code to
> demand more constrained behaviors is a defect in the Standard. The
> freedoms which hyper-modern compiler writers are claiming with respect
> to UB won't improve optimizations, but quite the opposite, as they will
> force programmers to write huge amounts of ugly and inefficient code for
> the purpose of ensuring that compilers never get to use the freedoms
> they've claimed for themselves.

That would be odd, because currently, the amount of ugly and inefficient
code required to avoid undefined behavior is relatively minor.

>> As far as I can tell, every signed type (including signed char) can have
>> the same positive range, whether or not unsigned types have any padding
>> bits. Could you explain why you think unsigned padding bits would be
>> needed in order for such an implementation to be conforming?
> 
> While it's often possible to work around C's lack of UB-safe integer
> math by converting values to unsigned types, using unsigned arithmetic,
> and then converting the results back to signed types, that will only
> work if unsigned types have more value bits than signed types--something
> which is not required by the Standard, and thus cannot be relied upon in
> a strictly-conforming program.

OK - I think you worded your comment poorly. You seemed to be saying
that an implementation in which all signed types had the same positive
type would not be legal unless the corresponding unsigned types had
padding bits.

Instead, it seems that you're saying that the signed types are the ones
that have to have padding bits, and the reason they need those bits is
not to legally conform to the standard, but only in order to make your
work-around work.

> Thus my challenge to you: can you offer a strictly-compliant version
> of "mulcomp" which yields the correct result in all cases defined by the
> current Standard, and has no side-effect other than yielding a value or
> terminating the program, and have such a function (1) be clear and
> understandable to a human, and (2) compile to code which is no more than
> twice as big and slow the original when given to the best available x86
> compiler [without cheating by omitting the code necessary to handle
> irksome integer sizes when using a platform with nicer ones].

No, I cannot. Avoiding unexpected side-effects on all platforms would
require detecting the possibility of overflow without actually creating
that possibility, and there's no simple and quick way of doing that.

The right way to do this is to ensure that overflow isn't a possibility
in the first place, by understanding your problem domain to set limits
on the possible range of the value of each expression (and possibly
validating your inputs to make sure that those ranges are satisfied),
and then making sure that each expression is evaluated using a data type
capable of representing that entire range. This may require rearranging
your calculations, and special handling of nasty cases. Sometimes
there's no such data type, which would require massive rearrangement of
your calculations. However, it isn't the horrible burden you imply that
it is.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-18 16:19 -0700
  Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-18 21:15 -0400
    Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-19 10:11 -0700
      Re: the language (and the role of Undefined Behavior therein) Ike Naar <ike@iceland.freeshell.org> - 2015-08-19 19:58 +0000
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-19 14:09 -0700
      Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-19 16:10 -0400
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-19 16:01 -0700
          Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-19 20:23 -0400
            Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 10:35 -0700
              Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-20 12:32 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 13:31 -0700
                Re: the language (and the role of Undefined Behavior therein) donalhambra@gmail.com - 2015-08-20 14:23 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 16:13 -0700
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-20 17:48 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-21 01:32 -0700
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-21 18:34 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-21 22:11 -0700
                Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-22 09:41 -0400
                Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-22 16:59 +0000
                Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:30 -0400
                Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-24 03:36 +0000
                Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:25 -0400
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 22:57 -0700
                Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-24 19:49 +0000
                Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:43 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 16:27 -0700
                Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-23 21:15 -0400
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 20:18 -0700
                Re: the language (and the role of Undefined Behavior therein) raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:37 +0000
                Re: the language (and the role of Undefined Behavior therein) David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 19:12 -0700
                Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:38 -0400
                Re: the language (and the role of Undefined Behavior therein) David Kleinecke <dkleinecke@gmail.com> - 2015-08-23 20:01 -0700
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-23 21:56 -0700
                Re: the language (and the role of Undefined Behavior therein) David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:25 -0700
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-24 18:21 -0700
                Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-24 22:22 -0400
                Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-25 14:31 +0000
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-25 09:22 -0700
                Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-25 18:55 +0000
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-25 12:33 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-25 16:23 -0700
                Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:31 -0400
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-24 10:32 -0700
                Re: the language (and the role of Undefined Behavior therein) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 23:54 -0700
                Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-24 03:45 +0000
                Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 08:11 -0700
      Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-23 18:46 -0400
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 19:04 -0700
          Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-23 23:40 -0400
            Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 22:48 -0700
              Re: the language (and the role of Undefined Behavior therein) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-24 00:38 -0700
  Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-18 21:22 -0400
  Re: the language (and the role of Undefined Behavior therein) Ike Naar <ike@iceland.freeshell.org> - 2015-08-20 21:44 +0000
    Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 16:48 -0700
    Re: the language (and the role of Undefined Behavior therein) Philip Lantz <prl@canterey.us> - 2015-08-20 23:41 -0700

csiph-web