Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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