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


Groups > comp.lang.c > #67903

Re: I want to ask a question...

From glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups comp.lang.c
Subject Re: I want to ask a question...
Date 2015-08-20 18:47 +0000
Organization Aioe.org NNTP Server
Message-ID <mr57b8$527$1@speranza.aioe.org> (permalink)
References (4 earlier) <lnmvxm3gwa.fsf@kst-u.example.com> <mr38rc$mbb$1@speranza.aioe.org> <lnio8a3akw.fsf@kst-u.example.com> <5620ecc0-0e7e-42a7-b389-4028db865a11@googlegroups.com> <lna8tl3iwn.fsf@kst-u.example.com>

Show all headers | View raw


Keith Thompson <kst-u@mib.org> wrote:
> supercat@casperkitty.com writes:
>> On Wednesday, August 19, 2015 at 9:33:27 PM UTC-5, Keith Thompson wrote:
>>> What do you mean by "what the program says"?  As far as the C standard
>>> is concerned, the program has no meaning if condition1 and condition2
>>> are both false.

>> There certainly exist platforms where comparing the pointer to 
>> null could trap, and there may be some where it would cause 
>> non-deterministic behavior, and there may thus be usefulness 
>> to allowing a dialect of C to be used on such platforms.  

(snip)
> The standard *does* recognize such behavior -- specifically by not
> constraining the range of permitted behaviors in any way.
 
> I'm not sure that the phrase "guaranteed not to cause Undefined
> Behavior" makes sense.  Undefined behavior is not some particular
> kind of behavior, like a program crash.  It means that the standard
> refrains from specifying what the behavior is.
 
> I think what you're actually suggesting is that a dialect of C
> could define the behavior of accessing a pointer value after the
> pointed-to object has reached the end of its lifetime.  That still
> leaves open the question of *how* it's to be defined.  Would it
> be implementation-defined or unspecified?  If so, the standard
> would have to specify a set of permitted behaviors from which
> an implementation may choose, with or without a requirement to
> document its choice.  Or would some specific behavior be specified?
> What would that behavior be?

At some point, as with many other things, it depends on the 
processor. Consider overflow, which might be less interesting
than pointers. Some trap on overflow, some don't, and many people
know what their processor does. 
 
> I would argue that accessing the value of an indeterminate pointer:
 
>    free(ptr);
>    if (ptr == NULL) /* ... */
 
> very probably indicates a bug in the program.  I want that bug
> diagnosed by the compiler if possible.  

No complaint here.

> Making the behavior undefined permits compilers to, for example, 
> generate code that causes the program to die with a clear error 
> message.  

But that isn't the discussion here.

> Making the behavior well-defined means that compilers cannot 
> reasonably diagnose the logical error (since, as far as the 
> language is concerned, it wouldn't be an error).

The case at hand is where compilers make optimizations based
on the UB, often with no message, and surprising results.
 
> Suppose a CPU is designed so that loading an invalid pointer into a
> register causes a trap.  Defining the behavior of a accessing such
> a pointer would mean that a compiler for such a CPU would have to
> generate extra code to ensure that that trap doesn't happen.

Well, x86 for x>=2. But compilers normally don't load segment
registers when not needed. (For one reason, it is slower.) 
Copying pointers in x86 (for any x) is normally done without
loading them into segment registers. There are no compare 
instructions for segment registers, so that isn't even a choice.
 
> There is one point on which I suspect we both agree: If a compiler
> is clever enough to take advantage of undefined behavior to generate
> *surprising* code (for example, code that executes unconditionally
> even though it's protected by an "if"), it should issue a warning.
> It may be difficult for the compiler to determine when such a
> warning is appropriate -- and issuing too many warnings is almost
> as bad as issuing too few.  But I'm sure there's plenty of work to
> be done in this area.

As far as I know, compiler technology isn't to the point where
such optimizations aren't done without the help of poeple. 
But maybe not so much longer. With an appropriate machine readable
form of the operation of each instruction, and without any thought
to how it might be used, it could happen.

-- glen

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


Thread

Re: I want to ask a question... Gareth Owen <gwowen@gmail.com> - 2015-08-07 20:00 +0100
  Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-07 19:04 +0000
  Re: I want to ask a question... Keith Thompson <kst-u@mib.org> - 2015-08-07 15:30 -0700
    Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-07 22:52 +0000
      Re: I want to ask a question... Keith Thompson <kst-u@mib.org> - 2015-08-07 16:46 -0700
        Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-07 23:29 +0000
          Re: I want to ask a question... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-08 01:37 +0100
          Re: I want to ask a question... Keith Thompson <kst-u@mib.org> - 2015-08-07 18:55 -0700
            Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-08 05:51 +0000
              Re: I want to ask a question... Robert Wessel <robertwessel2@yahoo.com> - 2015-08-08 01:44 -0500
    Re: I want to ask a question... Ken Brody <kenbrody@spamcop.net> - 2015-08-10 12:46 -0400
    Re: I want to ask a question... supercat@casperkitty.com - 2015-08-19 16:43 -0700
      Re: I want to ask a question... Keith Thompson <kst-u@mib.org> - 2015-08-19 18:09 -0700
        Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-20 01:00 +0000
          Re: I want to ask a question... Keith Thompson <kst-u@mib.org> - 2015-08-19 20:25 -0700
            Re: I want to ask a question... supercat@casperkitty.com - 2015-08-20 08:15 -0700
              Re: I want to ask a question... Keith Thompson <kst-u@mib.org> - 2015-08-20 11:38 -0700
                Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-20 18:47 +0000
                Re: I want to ask a question... supercat@casperkitty.com - 2015-08-20 14:01 -0700
            Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-20 16:43 +0000
              Re: I want to ask a question... James Kuyper <jameskuyper@verizon.net> - 2015-08-20 13:02 -0400
                Re: I want to ask a question... Tonton Th <tTh@nowhere.invalid> - 2015-08-20 17:40 +0000
                Re: I want to ask a question... James Kuyper <jameskuyper@verizon.net> - 2015-08-20 15:27 -0400
                Re: I want to ask a question... David Brown <david.brown@hesbynett.no> - 2015-08-20 22:58 +0200
                Re: I want to ask a question... James Kuyper <jameskuyper@verizon.net> - 2015-08-20 23:24 -0400
                Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-21 06:19 +0000
                Re: I want to ask a question... Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-21 09:20 -0600
                Re: I want to ask a question... supercat@casperkitty.com - 2015-08-22 12:25 -0700
                Re: I want to ask a question... Robert Wessel <robertwessel2@yahoo.com> - 2015-08-23 01:33 -0500
                Re: I want to ask a question... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-20 19:28 +0000
              Re: I want to ask a question... Keith Thompson <kst-u@mib.org> - 2015-08-20 12:11 -0700
          Re: I want to ask a question... David Brown <david.brown@hesbynett.no> - 2015-08-20 10:02 +0200
        Re: I want to ask a question... raltbos@xs4all.nl (Richard Bos) - 2015-08-22 13:42 +0000
          Re: I want to ask a question... supercat@casperkitty.com - 2015-08-22 12:23 -0700

csiph-web