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

Groups > comp.lang.c > #150634 > unrolled thread

"How one word broke C"

Back to article view | Back to comp.lang.c

Contents

  "How one word broke C" Lynn McGuire <lynnmcguire5@gmail.com> - 2020-03-17 14:29 -0500
    Re: "How one word broke C" Real Troll <Real.Troll@Trolls.com> - 2020-03-17 15:40 -0400
      Re: "How one word broke C" John Bode <jfbode1029@gmail.com> - 2020-03-19 11:57 -0700
        Re: "How one word broke C" James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-19 18:20 -0400
    Re: "How one word broke C" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-17 13:39 -0700
      Re: "How one word broke C" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-17 21:55 +0000
    Re: "How one word broke C" felix@palmen-it.de (Felix Palmen) - 2020-03-17 23:02 +0100
      Re: "How one word broke C" Richard Damon <Richard@Damon-Family.org> - 2020-03-17 21:57 -0400
        Re: "How one word broke C" Dan Purgert <dan@djph.net> - 2020-03-18 11:02 +0000
          Re: "How one word broke C" Richard Damon <Richard@Damon-Family.org> - 2020-03-18 08:58 -0400
            Re: "How one word broke C" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-18 06:04 -0700
              Re: "How one word broke C" Richard Damon <Richard@Damon-Family.org> - 2020-03-18 09:53 -0400
            Re: "How one word broke C" felix@palmen-it.de (Felix Palmen) - 2020-03-18 14:46 +0100
              Re: "How one word broke C" Richard Damon <Richard@Damon-Family.org> - 2020-03-19 08:55 -0400
        Re: "How one word broke C" Philipp Klaus Krause <pkk@spth.de> - 2020-03-18 18:21 +0100
          Re: "How one word broke C" already5chosen@yahoo.com - 2020-03-18 12:11 -0700
            Re: "How one word broke C" Philipp Klaus Krause <pkk@spth.de> - 2020-03-18 21:06 +0100
              Re: "How one word broke C" Richard Damon <Richard@Damon-Family.org> - 2020-03-18 22:43 -0400
                Re: "How one word broke C" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 07:18 -0700
          Re: "How one word broke C" Dan Purgert <dan@djph.net> - 2020-03-19 01:40 +0000
        Re: "How one word broke C" Eli the Bearded <*@eli.users.panix.com> - 2020-03-18 19:12 +0000
          Re: "How one word broke C" Philipp Klaus Krause <pkk@spth.de> - 2020-03-18 21:09 +0100
      Re: "How one word broke C" David Brown <david.brown@hesbynett.no> - 2020-03-18 21:35 +0100
        Re: "How one word broke C" felix@palmen-it.de (Felix Palmen) - 2020-03-18 23:27 +0100
          Re: "How one word broke C" Richard Damon <Richard@Damon-Family.org> - 2020-03-19 08:57 -0400
            Re: "How one word broke C" felix@palmen-it.de (Felix Palmen) - 2020-03-19 15:00 +0100
          Re: "How one word broke C" David Brown <david.brown@hesbynett.no> - 2020-03-19 15:02 +0100
            Re: "How one word broke C" felix@palmen-it.de (Felix Palmen) - 2020-03-19 15:10 +0100
              Re: "How one word broke C" gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-19 14:34 +0000
                Re: "How one word broke C" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-19 07:44 -0700
                  Re: "How one word broke C" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-19 14:57 +0000
                  Re: "How one word broke C" felix@palmen-it.de (Felix Palmen) - 2020-03-19 15:58 +0100
                    Re: "How one word broke C" David Brown <david.brown@hesbynett.no> - 2020-03-19 16:26 +0100
                Re: "How one word broke C" David Brown <david.brown@hesbynett.no> - 2020-03-19 16:08 +0100
                  Troll, gadfly, whatever... (Was: "How one word broke C") gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-21 11:08 +0000
                    Re: Troll, gadfly, whatever... (Was: "How one word broke C") Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-21 04:50 -0700
              Re: "How one word broke C" David Brown <david.brown@hesbynett.no> - 2020-03-19 16:04 +0100
                Re: "How one word broke C" felix@palmen-it.de (Felix Palmen) - 2020-03-19 16:16 +0100
                  Re: "How one word broke C" Richard Damon <Richard@Damon-Family.org> - 2020-03-19 23:36 -0400
            Re: "How one word broke C" James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-19 18:13 -0400
    Re: "How one word broke C" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-03-17 19:43 -0600
      Re: "How one word broke C" John Bode <jfbode1029@gmail.com> - 2020-03-24 16:07 -0700
    Re: "How one word broke C" James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-24 19:41 -0400

Page 1 of 3  [1] 2 3  Next page →

#150634 — "How one word broke C"

"How one word broke C"
    https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/

"A lot have been written about the dangers of “Undefined behavior” in C. 
  Its an often cited reason why C is a “Dangerous” language that invites 
hard to find bugs, and security issues.  In my opinion Undefined 
behavior is not inherently bad.  C is meant to be implementable on lots 
of different platforms and, to require all of them to behave in the 
exact same way would be impractical, it would limit hardware development 
and make C less future proof.  Some of the concerns around undefined 
behavior in C are based on the fact that C is a small enough language 
that all corners of the language are explored and actually matter."

Lynn

[toc] | [next] | [standalone]

#150635

On 17/03/2020 19:29, Lynn McGuire wrote:
> "How one word broke C"
>    https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/
>
> "A lot have been written about the dangers of “Undefined behavior” in 
> C.  Its an often cited reason why C is a “Dangerous” language that 
> invites hard to find bugs, and security issues.  In my opinion 
> Undefined behavior is not inherently bad.  C is meant to be 
> implementable on lots of different platforms and, to require all of 
> them to behave in the exact same way would be impractical, it would 
> limit hardware development and make C less future proof. Some of the 
> concerns around undefined behavior in C are based on the fact that C 
> is a small enough language that all corners of the language are 
> explored and actually matter."
>
> Lynn

What is undefined behaviour?   Please tell us or at least tell me.

[toc] | [prev] | [next] | [standalone]

#150702

On Tuesday, March 17, 2020 at 2:37:40 PM UTC-5, Real Troll wrote:
> On 17/03/2020 19:29, Lynn McGuire wrote:
> > "How one word broke C"
> >    https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/
> >
> > "A lot have been written about the dangers of “Undefined behavior” in 
> > C.  Its an often cited reason why C is a “Dangerous” language that 
> > invites hard to find bugs, and security issues.  In my opinion 
> > Undefined behavior is not inherently bad.  C is meant to be 
> > implementable on lots of different platforms and, to require all of 
> > them to behave in the exact same way would be impractical, it would 
> > limit hardware development and make C less future proof. Some of the 
> > concerns around undefined behavior in C are based on the fact that C 
> > is a small enough language that all corners of the language are 
> > explored and actually matter."
> >
> > Lynn
> 
> What is undefined behaviour?   Please tell us or at least tell me.

From N1570 (2011 pre-publication draft):

> 3.4.3
>
> 1 undefined behavior
>
> behavior, upon use of a nonportable or erroneous program construct or of erroneous 
> data, for which this International Standard imposes no requirements
>
> 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with 
> unpredictable results, to behaving during translation or program execution in a 
> documented manner characteristic of the environment (with or without the issuance of a 
> diagnostic message), to terminating a translation or execution (with the issuance of a 
> diagnostic message).
>
> 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow

Basically, there are certain classes of errors where the implementation is free handle
however it wants to - the language definition places no requirements on it or the runtime
environment to handle the situation in any particular way. 

[toc] | [prev] | [next] | [standalone]

#150704

On 3/19/20 2:57 PM, John Bode wrote:
> On Tuesday, March 17, 2020 at 2:37:40 PM UTC-5, Real Troll wrote:
...
>> What is undefined behaviour?   Please tell us or at least tell me.
> 
> From N1570 (2011 pre-publication draft):
> 
>> 3.4.3
>>
>> 1 undefined behavior
>>
>> behavior, upon use of a nonportable or erroneous program construct or of erroneous 
>> data, for which this International Standard imposes no requirements
>>
>> 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with 
>> unpredictable results, to behaving during translation or program execution in a 
>> documented manner characteristic of the environment (with or without the issuance of a 
>> diagnostic message), to terminating a translation or execution (with the issuance of a 
>> diagnostic message).
>>
>> 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow
> 
> Basically, there are certain classes of errors where the implementation is free handle
> however it wants to - the language definition places no requirements on it or the runtime
> environment to handle the situation in any particular way. 
> 

Note, in particular, the phrase "this International Standard". Code has
"undefined behavior" according to the C standard, even if  the behavior
is defined by some other document.

"undefined behavior" is NOT a particular kind of behavior; it is a
complete absence of any requirements imposed on the behavior (by ("this
International Standard"). You can't use the way translated source code
behaves to determine that the behavior is undefined - the only way you
can determine it is by analyzing the source code itself.

[toc] | [prev] | [next] | [standalone]

#150636

Lynn McGuire <lynnmcguire5@gmail.com> writes:
> "How one word broke C"
>    https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/
>
> "A lot have been written about the dangers of “Undefined behavior” in
> C. Its an often cited reason why C is a “Dangerous” language that
> invites hard to find bugs, and security issues.  In my opinion
> Undefined behavior is not inherently bad.  C is meant to be
> implementable on lots of different platforms and, to require all of
> them to behave in the exact same way would be impractical, it would
> limit hardware development and make C less future proof.  Some of the
> concerns around undefined behavior in C are based on the fact that C
> is a small enough language that all corners of the language are
> explored and actually matter."

I saw that article via Hacker News
<https://news.ycombinator.com/item?id=22589657>.

I'll copy the comment I posted there (with a typo corrected):

    The author claims that:
    > In C89, undefined behavior is interpreted as, “The C standard
    > doesn’t have requirements for the behavior, so you must define
    > what the behavior is in your implementation, and there are a few
    > permissible options”.

    That's a serious misinterpretation. C89 says that "Permissible
    undefined behavior" includes "ignoring the situation completely with
    unpredictable results". There is absolutely no requirement to
    document what those "unpredictable results" might be.

    The standard joke is that one possible consequence of undefined
    behavior is making demons fly out of your nose -- not because that's
    actually possible, but because actually making demons fly out of
    your nose would not violate the standard. That's equally true in C89
    and all later versions of C. The change in C99 from "Permissible" to
    "Possible" made no difference. The phrase "imposes no requirements"
    has always meant exactly that. (And if you think the change from
    "Permissible" to "Possible" is semantically significant, then it
    would have been a recognition of what was already accepted.)

    The idea of "nasal demons" goes back to
    1992. http://catb.org/jargon/html/N/nasal-demons.html

There are certainly arguments to be made about how C defines and treats
"undefined behavior", but the author's claim that C99's change from
"Permissible" to "Possible" made a significant difference is incorrect.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#150637

On Tue, 2020-03-17, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> "How one word broke C"
>>    https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/
>>
>> "A lot have been written about the dangers of “Undefined behavior” in
>> C. Its an often cited reason why C is a “Dangerous” language that
>> invites hard to find bugs, and security issues.  In my opinion
>> Undefined behavior is not inherently bad.  C is meant to be
>> implementable on lots of different platforms and, to require all of
>> them to behave in the exact same way would be impractical, it would
>> limit hardware development and make C less future proof.  Some of the
>> concerns around undefined behavior in C are based on the fact that C
>> is a small enough language that all corners of the language are
>> explored and actually matter."
>
> I saw that article via Hacker News
> <https://news.ycombinator.com/item?id=22589657>.
>
> I'll copy the comment I posted there (with a typo corrected):
>
>     The author claims that:
>     > In C89, undefined behavior is interpreted as, “The C standard
>     > doesn’t have requirements for the behavior, so you must define
>     > what the behavior is in your implementation, and there are a few
>     > permissible options”.
>
>     That's a serious misinterpretation.

Sigh.  How hard can it be to understand the concept of nasal demons?
I'm so bored with the whole thing popping up over and over again.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150638

* Lynn McGuire <lynnmcguire5@gmail.com>:
> "How one word broke C"
>    https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/
> 
> " [...]                                  In my opinion Undefined 
> behavior is not inherently bad.  C is meant to be implementable on lots 
> of different platforms and, to require all of them to behave in the 
> exact same way would be impractical, it would limit hardware development 
> and make C less future proof. [...]                               "

That already misses the point. Most newer languages are “fully defined”
without restricting the platforms they can be implemented on
significantly. Practical portability might be a reason for
“implementation defined” bits in the standard, like the actual sizes of
some types, the representation of negative numbers, etc... They often
allow an implementation to map efficiently to instructions of the target
platform, but require that the behavior is reliable and documented.

But for *undefined* behavior, the reason is more likely that diagnosing
a program triggering it would only be possible at runtime. C is designed
with as little as possible overhead in mind, so a large runtime
environment doing all sorts of checks isn't necessary. The cost for this
kind of efficiency is UB.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

[toc] | [prev] | [next] | [standalone]

#150640

On 3/17/20 6:02 PM, Felix Palmen wrote:
> * Lynn McGuire <lynnmcguire5@gmail.com>:
>> "How one word broke C"
>>    https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/
>>
>> " [...]                                  In my opinion Undefined 
>> behavior is not inherently bad.  C is meant to be implementable on lots 
>> of different platforms and, to require all of them to behave in the 
>> exact same way would be impractical, it would limit hardware development 
>> and make C less future proof. [...]                               "
> 
> That already misses the point. Most newer languages are “fully defined”
> without restricting the platforms they can be implemented on
> significantly. Practical portability might be a reason for
> “implementation defined” bits in the standard, like the actual sizes of
> some types, the representation of negative numbers, etc... They often
> allow an implementation to map efficiently to instructions of the target
> platform, but require that the behavior is reliable and documented.
> 
> But for *undefined* behavior, the reason is more likely that diagnosing
> a program triggering it would only be possible at runtime. C is designed
> with as little as possible overhead in mind, so a large runtime
> environment doing all sorts of checks isn't necessary. The cost for this
> kind of efficiency is UB.
> 

I see that there are just a few basic reasons that some things were made
to be 'undefined behavior' in C, and will say that considering the
history a purose of C they make sense.

One big class are error caused by separate compilation with very simple
object modules. Mixing the usage of a name that is defined differently
in different compilations was just too hard to define, and to force a
pre-link consistency check to catch them was too expensive.

Related are problems that would require the compiler to be too
sophisticated to detect. C was designed to be possible to compiler with
a very primitive one pass compiler (but also allowing a smarter compiler
to do better(,

Another major class of things that became undefined behavior were things
that differed significantly between machines, and some machines would
trap in that case. Traps were beyond what was wanted in most
implementation defined behavior, and normally the case involved some
form of error (overflow of some type, numbers out of range, etc) so
rather than spending the effort to figure out a way to specify it, it
was just left undefined.

Some undefined behavior comes from the desire to permit some useful and
powerful optimization, but some oddball case, that if allowed, would
break the ability to make that optimization.

One thing to remember also is that machines were much more varied back
then in the early stages of the language, with a number of very strange
machines, so some things that today seem easy enough to make
implementation defined weren't so easy to define. While machines have
gotten more standardized, optimizations that some people think as
important have been developed on the assumption that code doesn't do any
of they operations with undefined behavior,

Another big thing to remember is that just because an action is declared
to produce undefined behavior in the standard, doesn't mean that a
program can't validly do that and have an proper expectation of results,
as UB just says that the Standard doesn't define it, but most programs
don't need absolute portability to every possible implementation and
some other standard or the implementation can define the behavior and
allow it to be used.

[toc] | [prev] | [next] | [standalone]

#150641

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Richard Damon wrote:
> [...]
> One thing to remember also is that machines were much more varied back
> then in the early stages of the language, [...]

This, right here, is probably the most key aspect of the entire thing.
People seem to have forgotten that the IBM (and clone) monoculture based
on Windows / Intel processors is CONSIDERABLY newer than C.


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl5x/8YACgkQjhHd8xJ5
ooEqpwf9HKlXeWJO2BFdQfPmZBH3nxqjTbkOAEJodEh9NEnYNjrDBqIIFW/1R8fK
DkF8PygtE3ui6LOhYcD6if2NyHbsTa5zOIYcWaFbW1rKC/kklGSg36tG1GEIJYJC
nUYfWRYPXwd+ru6s7lGvN3VTzmPiE1AcezY4t2EZXmPS80X0JZSF9vxcqTjH+CcG
1iOayGmLyIqYysPzy4mFaqZkGVLCP7KHnU/eJ+RcE30vo60tplSiPIYrZuVzWGdU
To+69eaQbXIZpW17/9Nbz9h8J1qd0ZaVNAsHhrCEJHMgUvwT8ushcSHDJ/iv+MVl
L++mBPsmLN1zpeJdSHNd36+Uy6dEUg==
=Ir7V
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#150642

On 3/18/20 7:02 AM, Dan Purgert wrote:
> Richard Damon wrote:
>> [...]
>> One thing to remember also is that machines were much more varied back
>> then in the early stages of the language, [...]
> 
> This, right here, is probably the most key aspect of the entire thing.
> People seem to have forgotten that the IBM (and clone) monoculture based
> on Windows / Intel processors is CONSIDERABLY newer than C.
> 

Yes, I would say that virtually ALL of the things made undefined
behavior is due to the fact that there was some machine of importance
(not just an academic curiosity) couldn't define the behavior simply
without needing to add run time test (which hurt efficiency).

And most of the unspecified/implementation defined behavior was due to
differing machine characteristics, or in some cases different
implementations took different paths on things left under-specified in
the early language descriptions. There are a few things left
unspecified, like order of evaluation, because on some machines that
allows an improvement in efficiency.

[toc] | [prev] | [next] | [standalone]

#150643

On Wednesday, 18 March 2020 12:58:44 UTC, Richard Damon  wrote:
> On 3/18/20 7:02 AM, Dan Purgert wrote:
> > Richard Damon wrote:
> >> [...]
> >> One thing to remember also is that machines were much more varied back
> >> then in the early stages of the language, [...]
> > 
> > This, right here, is probably the most key aspect of the entire thing.
> > People seem to have forgotten that the IBM (and clone) monoculture based
> > on Windows / Intel processors is CONSIDERABLY newer than C.
> > 
> 
> Yes, I would say that virtually ALL of the things made undefined
> behavior is due to the fact that there was some machine of importance
> (not just an academic curiosity) couldn't define the behavior simply
> without needing to add run time test (which hurt efficiency).
> 
> And most of the unspecified/implementation defined behavior was due to
> differing machine characteristics, or in some cases different
> implementations took different paths on things left under-specified in
> the early language descriptions. There are a few things left
> unspecified, like order of evaluation, because on some machines that
> allows an improvement in efficiency.
>
Basically the problem was that C allowed raw pointers. So you could set a
pointer to an invalid value, then dereference it. You can't get round that
problem without fundamentally changing the language.

[toc] | [prev] | [next] | [standalone]

#150645

On 3/18/20 9:04 AM, Malcolm McLean wrote:
> On Wednesday, 18 March 2020 12:58:44 UTC, Richard Damon  wrote:
>> On 3/18/20 7:02 AM, Dan Purgert wrote:
>>> Richard Damon wrote:
>>>> [...]
>>>> One thing to remember also is that machines were much more varied back
>>>> then in the early stages of the language, [...]
>>>
>>> This, right here, is probably the most key aspect of the entire thing.
>>> People seem to have forgotten that the IBM (and clone) monoculture based
>>> on Windows / Intel processors is CONSIDERABLY newer than C.
>>>
>>
>> Yes, I would say that virtually ALL of the things made undefined
>> behavior is due to the fact that there was some machine of importance
>> (not just an academic curiosity) couldn't define the behavior simply
>> without needing to add run time test (which hurt efficiency).
>>
>> And most of the unspecified/implementation defined behavior was due to
>> differing machine characteristics, or in some cases different
>> implementations took different paths on things left under-specified in
>> the early language descriptions. There are a few things left
>> unspecified, like order of evaluation, because on some machines that
>> allows an improvement in efficiency.
>>
> Basically the problem was that C allowed raw pointers. So you could set a
> pointer to an invalid value, then dereference it. You can't get round that
> problem without fundamentally changing the language.
> 

That is one fundamental source of Undefined Behavior which directly
derives from C desire to allow the generation of as efficient code as
possible, and includes an implicit trust of the programmer to allow for
that.

It should be noted, that an implementation with properly checked
pointers can be fully conforming, as the out of bounds access could
easily turned into always trapping. You might run into issues with some
code that uses derived knowledge of the implementation that says that a
certain access should act in a given way, but that code is technically
broken to begin with.

[toc] | [prev] | [next] | [standalone]

#150644

* Richard Damon <Richard@damon-family.org>:
> Yes, I would say that virtually ALL of the things made undefined
> behavior is due to the fact that there was some machine of importance
> (not just an academic curiosity) couldn't define the behavior simply
> without needing to add run time test (which hurt efficiency).

That might be true, given that modern compilers can detect some
undefined behavior with just static analysis.

Still there's a class of undefined behavior that could *only* be
detected at runtime, no matter how the target machine looks like. A
typical example is an out-of-bounds array access to an array defined in
a different compilation unit, or allocated at runtime with a calculated
size. That's why I said the main reason to have UB in the language
specification at all was to avoid any expensive runtime support.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

[toc] | [prev] | [next] | [standalone]

#150684

On 3/18/20 9:46 AM, Felix Palmen wrote:
> * Richard Damon <Richard@damon-family.org>:
>> Yes, I would say that virtually ALL of the things made undefined
>> behavior is due to the fact that there was some machine of importance
>> (not just an academic curiosity) couldn't define the behavior simply
>> without needing to add run time test (which hurt efficiency).
> 
> That might be true, given that modern compilers can detect some
> undefined behavior with just static analysis.
> 
> Still there's a class of undefined behavior that could *only* be
> detected at runtime, no matter how the target machine looks like. A
> typical example is an out-of-bounds array access to an array defined in
> a different compilation unit, or allocated at runtime with a calculated
> size. That's why I said the main reason to have UB in the language
> specification at all was to avoid any expensive runtime support.
> 

Subscripting errors don't ALWAYS need run time tests, sometimes the
compiler can prove that an error will, or will not occur at a given
point by knowledge of what the code around it does, but in general it
does, and that falls easily within my statement, as if all machines
require it, then surely some do (unless there are no machines).

These are the behaviors, that can invoke unbounded write, are the ones
that come the closest to actually creating the 'Nasal Demons'.

There are a lot of other cases where perhaps the results could have been
described in most cases as an indeterminate result or an implementation
defined trap, but the early standard hadn't developed a name for that
category, as the next level down from Undefined Behavior was Unspecified
Behavior, which generally didn't include the concept of generating a
trap that might terminate the program.

Now, because optimizations have been developed base on the assumption
that UB doesn't occur, (or that if it does, there are no requirements on
what happens), so restricting what happens in those cases will lose
efficiency for some programs.

As I said before, there is nothing in the Standard to prevent an
implementation from defining some of these behaviors more tightly, and
many do allow this optionally.

There is probably room for either a set of optional annexes, or
supplemental standards to include definitions of many of the things that
are currently undefined because of ancient strange architectures (using
plural as some may be less universal than others). But even on machines
where the behavior can readily be defined, there are still cases where
you might want to operate in an environment where some of these generate
traps to detect program errors (things like overflows)

Some of the assumptions I could see being added to better define behavior:

Twos Complement integers with no trap representations and wrapping on
overflows (cases perhaps separable)

Byte Accessible memories (all object pointers have same size and
representation, but some types of objects need alignment.)

Flat address space (all object pointers are order comparable, not just
those to parts of the same object)

Function Pointers and Object pointers are same size and representation
(so a void* is able to hold a function pointer too)

[toc] | [prev] | [next] | [standalone]

#150649

Am 18.03.20 um 02:57 schrieb Richard Damon:
> One thing to remember also is that machines were much more varied back
> then in the early stages of the language

Don't forget about Itanium. Some machines still exist, and are even
supported as a target by GCC 10 (though deprecated and to be removed for
GCC 11), a current C compiler.

[toc] | [prev] | [next] | [standalone]

#150665

On Wednesday, March 18, 2020 at 7:22:01 PM UTC+2, Philipp Klaus Krause wrote:
> Am 18.03.20 um 02:57 schrieb Richard Damon:
> > One thing to remember also is that machines were much more varied back
> > then in the early stages of the language
> 
> Don't forget about Itanium. Some machines still exist, and are even
> supported as a target by GCC 10 (though deprecated and to be removed for
> GCC 11), a current C compiler.

Itanium is quite similar to few other supported gcc targets. Yet another byte-addressable machine with two-complement arithmetic, 4byte words, 8byte double words and 8byte pointers, run-of-the-mill assortment of arithmetic, logic and shift operations. And absence of integer divide instruction is not extraordinary. Mandatory "natural" alignment of 4-byte and 8-byte numbers is required by few other gcc targets as well.
So, generation of correct Itanium code is quite easy.
Now, generation of *fast* Itanium code is quite hard, but that's appear completely unrelated to the theme of this thread.

[toc] | [prev] | [next] | [standalone]

#150667

Am 18.03.20 um 20:11 schrieb already5chosen@yahoo.com:> Itanium is quite
similar to few other supported gcc targets. Yet
> another byte-addressable machine with two-complement arithmetic,
> 4byte words, 8byte double words and 8byte pointers, run-of-the-mill
> assortment of arithmetic, logic and shift operations. And absence of
> integer divide instruction is not extraordinary. Mandatory "natural"
> alignment of 4-byte and 8-byte numbers is required by few other gcc
> targets as well. So, generation of correct Itanium code is quite
> easy.

Thanks to undefined behaviour. Otherwise the trap representations would
be a problem (reading uninitialized local variables can actually crash
programs on Itanium).

[toc] | [prev] | [next] | [standalone]

#150680

On 3/18/20 4:06 PM, Philipp Klaus Krause wrote:
> Am 18.03.20 um 20:11 schrieb already5chosen@yahoo.com:> Itanium is quite
> similar to few other supported gcc targets. Yet
>> another byte-addressable machine with two-complement arithmetic,
>> 4byte words, 8byte double words and 8byte pointers, run-of-the-mill
>> assortment of arithmetic, logic and shift operations. And absence of
>> integer divide instruction is not extraordinary. Mandatory "natural"
>> alignment of 4-byte and 8-byte numbers is required by few other gcc
>> targets as well. So, generation of correct Itanium code is quite
>> easy.
> 
> Thanks to undefined behaviour. Otherwise the trap representations would
> be a problem (reading uninitialized local variables can actually crash
> programs on Itanium).
> 

That behavior is actually quite old. There were machines that had
instructions to erase a word of core to a bad memory value (bad parity)
and if that word was later read before it was written to the program
would trap on the parity error.

[toc] | [prev] | [next] | [standalone]

#150858

Richard Damon <Richard@Damon-Family.org> writes:

> On 3/18/20 4:06 PM, Philipp Klaus Krause wrote:
>
>> Am 18.03.20 um 20:11 schrieb already5chosen@yahoo.com:> Itanium is quite
>> similar to few other supported gcc targets.  Yet
>>
>>> another byte-addressable machine with two-complement arithmetic,
>>> 4byte words, 8byte double words and 8byte pointers, run-of-the-mill
>>> assortment of arithmetic, logic and shift operations.  And absence of
>>> integer divide instruction is not extraordinary.  Mandatory "natural"
>>> alignment of 4-byte and 8-byte numbers is required by few other gcc
>>> targets as well.  So, generation of correct Itanium code is quite
>>> easy.
>>
>> Thanks to undefined behaviour.  Otherwise the trap representations would
>> be a problem (reading uninitialized local variables can actually crash
>> programs on Itanium).
>
> That behavior is actually quite old.  There were machines that had
> instructions to erase a word of core to a bad memory value (bad parity)
> and if that word was later read before it was written to the program
> would trap on the parity error.

Yes but such things have not always been undefined behavior.  In
C90, reading any uninitialized (auto) variable is UB.  In C99,
reading an uninitialized variable is UB only if the stored value
is a trap representation;  a type that doesn't have any trap
representations (which these days includes most integer types in
most implementations) cannot transgress into UB land.  It wasn't
until C11 that the Standard added a provision that specifies UB
for such accesses, and even then only for variables that do not
have their address taken.  It is the C11 rule that allows UB
for Itanium-style variables, which can trap even though their
type has no trap representations.

[toc] | [prev] | [next] | [standalone]

#150679

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Philipp Klaus Krause wrote:
> Am 18.03.20 um 02:57 schrieb Richard Damon:
>> One thing to remember also is that machines were much more varied back
>> then in the early stages of the language
>
> Don't forget about Itanium. Some machines still exist, and are even
> supported as a target by GCC 10 (though deprecated and to be removed for
> GCC 11), a current C compiler.

Yeah, but that doesn't negate what I said about the (effective)
monoculture of the last two decades or so.


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl5yzagACgkQjhHd8xJ5
ooEO8QgAj1MFSvWKSffDyRT4MWO1BqcisEjiVgqWdD++NlJyUsWjFsCZBf/94mDv
kqTfomOyQb8Ba/JQwmqmvffhgbc6eOxdJV6bL7HrtaSVnD6dqCtlOE1ctzzo9p8Z
PQHxIe3YlNrh16Kl1kgZ+da1WOCcbus3vLevrIecMBRa+0uGusRp0j1ds1iznlAI
pkMXygsQQQ0dX2TUgCrEx945EMcNRAotEUv1OojSTTdi0uisWRQIFlwNQySP/j3/
02OIgkayHuLBy+qVR3/BSDj/4vV8hP6cFLMYOiV0nbdlXcS3HYch9OCNDQvv7cnc
6F4rCR5G0l2PL8nwo1K0zr+Bh64QmQ==
=1s4/
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web