Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Knowing the implementation, are all undefined behaviours become implementation-defined behaviours?

Reply
Thread Tools

Knowing the implementation, are all undefined behaviours become implementation-defined behaviours?

 
 
Nick Keighley
Guest
Posts: n/a
 
      02-16-2010
On 16 Feb, 08:12, tonydee <(E-Mail Removed)> wrote:

> [this] suggests you
> believe CHAR_BIT >= 8. *I've heard rumours of systems where it was 7 [...]


CHAR_BIT cannot be less than 8 on a standard conforming C (or C++)
implementation
 
Reply With Quote
 
 
 
 
tonydee
Guest
Posts: n/a
 
      02-16-2010
On Feb 16, 5:27*pm, Richard Heathfield <(E-Mail Removed)> wrote:
> [I note the cross-post to clc++. My answer is given in a C context,
> which may or may not also apply to C++.]
>
> tonydee wrote:
> > On Feb 14, 10:23 pm, pete <(E-Mail Removed)> wrote:

>
> >> I think it is simplest to consider
> >> the behavior of an otherwise correct
> >> program which executes this statement
> >> * * *return (1 / (CHAR_BIT - 7));
> >> as being implementation defined

>
> > I don't believe that your example is implementation defined vis--vis
> > the Standard.

>
> The CHAR_BIT - 7 one is implementation-defined. The implementation
> defines it by defining CHAR_BIT (as it is required to do), which is at
> least 8 but which can be greater. So the result of the expression 1 /
> (CHAR_BIT - 7) will be 1 unless CHAR_BIT exceeds 8, in which case it
> will be 0.


The _value_ of CHAR_BIT is implementation defined. Programs that
incorporate the value into the division above always receive a result
that's entirely specified - as a function of the inputs - by the
Standard. The division process and behaviour are well defined. I
don't think it's correct or useful to imagine that all behaviour
consequent to something implementation defined is itself
implementation defined.

If we look at what was being said:

> >> I think it is simplest to consider
> >> the behavior of an otherwise correct
> >> program which executes this statement
> >> return (1 / (CHAR_BIT - 7));
> >> as being implementation defined


Surely it is implied that it's the use of CHAR_BIT in the division,
and not CHAR_BIT itself, which might make the expression
implementation defined? I'm saying that in that exact but limited
sense, it's moved past the implementation defined aspect and division
behaviour is well defined.

> When we shift to CHAR_BIT - 9, however, the result can be -1 (for
> CHAR_BIT of , or 1 (for CHAR_BIT of 10), or 0 (for CHAR_BIT of 11+),
> or undefined (for CHAR_BIT of 9). So, if all we can observe is the
> source (i.e. we don't know the implementation), the safest observation
> we can make is that the code exhibits undefined behaviour and should be
> changed.


Again, this misses the subtlety I was trying to communicate. "The
code exhibits undefined behaviour" is misleading. It's only exhibited
when it happens. It certainly _can_ exhibit undefined behaviour, but
there are many environments where it will run with well-defined
behaviour. There may even be a compile time assertion that CHAR_BIT !
= 9 somewhere above. While any good program would handle this issue
is a robust fashion, but it's not a precondition for avoiding
undefined behaviour when the implementation has CHAR_BIT != 9. It
boils down to a defensive programming consideration.

> > If your code divides 1 by some positive value, that has a well-defined
> > meaning and flow of control that is common to all C++ compilers/
> > environments, though the exact divisor and result may vary. *Nothing
> > here needs to be documented per implementation.

>
> CHAR_BIT does. Since the result of the expression depends on that value,
> the behaviour is effectively implementation-defined.


(Discussed again above.)

Cheers,
Tony
 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      03-01-2010
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard Tobin) wrote:

> In article <(E-Mail Removed)>,
> Seebs <(E-Mail Removed)> wrote:
>
> > while (ptr != 0) {
> > /* blah blah blah */
> > ptr = get_ptr();
> > x = *ptr;
> > }
> >
> >gcc might turn the while into an if followed by an infinite loop, because
> >it *knows* that ptr can't become null during the loop, because if it did,
> >that would have invoked undefined behavior.

>
> As I've said before, the fact that the compiler can do this sort of
> optimisation is often an indication of an error in the code. Why
> would the programmer repeatedly test the pointer if it couldn't be
> null? I would much rather that the compiler warned about this, instead
> of just treating it as an opportunity to remove some code.


I'd much rather that it did both. I can see why you'd want a warning,
but I still want my compiler to optimise away a test which I'd not
realised was superfluous (or perhaps more likely, which is superfluous
on one architecture but not on another).

Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Become The master in computer hardware to become successfull shilla Computer Security 1 01-22-2011 06:19 PM
Knowing the implementation, are all undefined behaviours become implementation-defined behaviours? Michael Tsang C Programming 54 03-30-2010 07:46 AM
same code, different providers => different behaviours?? Bart ASP .Net 2 03-22-2007 10:25 AM
"Interesting" C behaviours Rennie deGraaf C Programming 6 11-28-2004 09:27 AM



Advertisments