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

Groups > comp.lang.c > #71933

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

Show all headers | View raw

supercat@casperkitty.com wrote:
> On Sunday, October 4, 2015 at 6:57:39 PM UTC-5, Tim Rentsch wrote:
>> Two, if you want people to take you seriously, it's important to
>> become more conversant with the Standard and use its terminology
>> in the same way the Standard does.  Perhaps that shouldn't be
>> true but IME there is a significant effect.
 
> Fair point; I think one of my difficulties is that I was 
> programming in C before there even *was* an ANSI Standard, 
> and so my perspective of the language is in significant measure 
> influenced by behaviors which were common to almost every compiler 
> for common platforms, but for various reasons the Standards 
> Committee has never acknowledged in any fashion.

Yes, I was also using C before ANSI, though not so long before.
 
> For example, while the Standards Committee has never said that 
> compilers should support pointer-based type punning, it emerged 
> as a common technique because it was useful, compilers consistently 
> supported it in practice, and because code written to exploit it 
> could in many cases be more efficient than any readable alternative.  

Without going back and looking, I believe it is system dependent.
You can't guarantee it, but if you know it works on yours,
you are allowed to use it.

> Whether or not the Standards Committee acknowledged type punning 
> as a technique which compilers should support by default in the 
> absence of a compelling reason to do otherwise, programmers and 
> compiler vendors both recognized it as such, and knew that it 
> should be supported as a technique whether or not the 
> C Standard mandated it.
 
> A lot of people seem to claim that pointer-based type punning 
> was never legitimate, but given that compilers consistently 
> recognized it before C89 was published, I'd say the difference 
> between the language defined by the Standard and the language 
> everyone was actually using was *not* due to poor programming 
> practices, but rather due to defects in the Standard which 
> were regarded as quaint oddities which would only be relevant if 
> one was targeting unusual platforms.

There has been hardware that disallows it. For more modern
system, JVM disallows it.  Also, some hardware has alignment
restrictions which can cause it to fail.
 
> I have a very strong suspicion that things like the restrictions 
> on pointer- based type punning were never intended to be used for 
> optimization purposes, but were rather intended to allow compilers 
> to enforce more rigid type checking should they choose to do so.  
> The rules would actually be fairly sensible if that was the 
> intended purpose, if coupled with the notion that implementations 
> might offer a choice of whether or not to enforce the rules, 
> in much the same fashion as many compilers for other languages 
> allow code to enable or disable array-subscript checking.

As noted, hardware might disallow it. There was a fairly strong
incentive to allow things that hardware allows, and disallow things
that hardware doesn't, even if the latter is relatively rare.
 
> In any case, I suspect what's happened is that people who were 
> not programming C in the 1980s and 1990s never got a sense for 
> the de-facto standard behaviors which went beyond those described 
> by the "official" Standard.

This goes back at least to the use of EQUIVALENCE in Fortran.

It is supposed to be used to save memory, but again has been
used to type pun. Early Fortran machines were word addressed.
Endianness wasn't a problem. 

But even in cases where type punning works, its use depends
on knowing the bit patterns, endianness, and padding, of the
values in use. For those reasons, the standard (I believe)
makes it system dependent. (Including that one might hit a
trap representation or alignment exception.)

-- glen

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-09-29 15:48 -0700
  Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:57 -0700
    Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-04 19:48 -0700
      Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:50 +0000
        Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 13:43 +0100
          Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 15:26 +0000
            Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 19:39 +0100
              Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-05 13:32 -0700
              Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 22:06 +0000
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-05 16:08 -0700
                Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-06 11:04 +0100
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-06 08:06 -0700
                Re: the language (and the role of Undefined Behavior therein) Rosario19 <Ros@invalid.invalid> - 2015-10-06 18:14 +0200
                Re: the language (and the role of Undefined Behavior therein) Rosario19 <Ros@invalid.invalid> - 2015-10-06 18:54 +0200
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-06 11:20 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-06 10:00 -0700
                Re: the language (and the role of Undefined Behavior therein) David Thompson <dave.thompson2@verizon.net> - 2015-10-31 06:44 -0400
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-31 11:08 -0700
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-10-31 13:53 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-31 14:06 -0700
          Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-05 09:28 -0700
          Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-10-05 11:20 -0700
            Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 20:13 +0100
              Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:29 -0700
      Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 10:32 -0700
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-12 12:23 -0700
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-12 14:42 -0700
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-14 09:10 -0700
          Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 16:11 -0700

csiph-web