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

Groups > comp.lang.c > #127171

Re: Opinion sought: Is this strictly conforming C?

Show all headers | View raw

On 01/03/18 00:19, supercat@casperkitty.com wrote:
> On Wednesday, February 28, 2018 at 3:32:02 PM UTC-6, David Brown wrote:
>> On 28/02/18 18:03, supercat@casperkitty.com wrote:
>>> On Wednesday, February 28, 2018 at 3:24:58 AM UTC-6, David Brown wrote:
>>>> Anyway, who /cares/ about behaviour of signed integer shifts with
>>>> negative numbers, and other such cases?  Use unsigned data when you need
>>>> to do bit manipulation.
>>>
>>> Anyone who has existing code which might use such things would care.
>>
>> People who used such code care mainly about it working on the particular 
>> platform and compiler they are using.  After all, the great majority of 
>> C code is only ever compiled for a single target, using one compiler - 
>> or at most within a small group of targets.  Portable code is a minority 
>> (an important minority, of course).
> 
> Most code performs tasks that would be practical on an open-ended set
> of platforms, but not on every imaginable platform.  I would suggest that
> making such code portable among general-purpose implementations for
> platforms that can support it would be both practical and useful.  The
> reason so little code is portable is that the Standard fails to provide
> means to accomplish many tasks in portable fashion.

Stop "suggesting", and try thinking.  Most code is written for a
specific purpose.  The programs written by companies in-house, or
compiled and delivered as executables, far outweigh the code in
libraries, or available as open source, or otherwise being widely portable.

So for most code, portability is irrelevant.  The code /might/ be
portable to any C compiler and any target, or it /might/ be portable to
a range of similar targets or compilers - or it might be tied tightly to
one compiler or one target.  In most cases, the programmer does not
care.  This has nothing to do with what the standards say or don't say -
it is a matter of what professional programmers do for a living.

> 
>>>  My
>>> bigger point is that this was a construct which was unambiguously defined
>>> in useful fashion on every common platform.
>>
>> No, it was never defined in any portable way.  Some compilers might have 
>> defined it in a particular way, but certainly nothing you could rely on 
>> for different compilers or different targets.
> 
> If an implementation uses two's-complement integers and neither signed nor
> unsigned types include padding bits, what latitude would C89 give it to
> process x<<1 as yielding anything other than x*2 in any case where the
> latter would be defined?  

C89 did not define what "left shifting" of a signed type means.  You can
make some guesses, based on other definitions and try to get a
consistent picture.  In particular, you can assume that if all values
are valid and can be represented, then left-shifting an unsigned value
as an unsigned type or a signed type should give the same result.  That
means "left shifting" must be in terms of logical bit value positions,
rather than the bits in the underlying representation.  But what happens
when you left-shift a signed integer?  There is no definition of what
that might mean in the C89 standards - it is undefined behaviour, and
can't even be guessed from other points.  In particular, it is /not/
implementation-defined behaviour (which needs to be stated explicitly,
as is the case for right-shifting negative numbers).  The nearest you
could guess is that it is an exceptional condition, and therefore
undefined behaviour.

C99 did not change anything here.  The text clarified that left-shifting
negative numbers is undefined behaviour.  The C99 rationale backs this
up - it does not mention the point, which it would have done if it had
been a change.

You can well say that left-shifting a negative number /should/ give x*2,
at least on two's complement systems.  Or you could say it /should/ be
implementation-defined.  But it is /not/ defined like that, and never
has been.  (And as always, implementations or other standards can give
it a definition - it is merely undefined by the C standards.)


> 
>>>  The definition was less than
>>> ideal on some obscure platforms [none of which have ever, so far as I can
>>> tell, received C99 implementations], but there was no plausible reason why
>>> the behavior should not have remained the same on common platforms, save
>>> only for the fact that it was simpler for the Standard to say that the
>>> behavior is Undefined on all platforms, than to recognize a category of
>>> platforms for which the Standard would describe the behavior, and a
>>> category of (as it happens, non-existent) platforms for which it would not.
>>
>> There you go again - thinking that because /you/ can't think of a reason 
>> for something, it must not be the case, or that the standards committee 
>> thought intended something other than what they wrote.  It does not 
>> /matter/ what you think, or what "plausible reasons" you can imagine, or 
>> fail to imagine.  It does not /matter/ how you think C used to work, or 
>> how you think some compilers work, or how you think some platforms work. 
>>   It does not /matter/ what platforms /you/ think are obscure or 
>> outdated.  It certainly does not matter what you think the Standards 
>> committees "intended" or did not intend.
> 
> If a Committee were to act in sufficiently outrageous fashion, it would
> be right and proper for everyone to ignore any standard they might publish.
> People may differ with regard to what level of conduct should be viewed as
> "sufficiently outrageous", and may regard as infinitesimal the likelihood of
> the Committee acting in such fashion.  Nonetheless, any authority the
> Committee may have should be predicated upon its acting at least somewhat
> reasonably.

And most people - C programmers, and C compiler writers - agree that the
committee is basically reasonable.  Pretty much everyone has points in
the standards that they would prefer to be defined differently, or at
least explained differently.  But the standards certainly work well
enough that they are a useful standard.

A few people - such as yourself - get hung up about minor little details
that are irrelevant to most code, and easily avoided.  If you are
"outraged" by the inability to left-shift negative numbers safely, then
I think you need to re-tune your "outrage" filters.

> 
> If the Committee decides to make a change which would break some existing
> code after they have weighed their options and determined that the advantages
> would outweigh the disadvantages, such action may be reasonable.  If they
> intend to break existing code for no reason whatsoever, that would be far
> less reasonable.

The Committee didn't change anything here.  And one of the prime
functions of the Committee has always been to look at existing code and
practices, and ensure that they /don't/ make breaking changes without
extremely good reason.  Most of the poor points about the C language
stem precisely from that principle.

> 
>> What matters is what the standards (the C standards, together with any 
>> other /relevant/ standards or documents for the platform) /say/.  And 
>> when they say something has undefined behaviour, compilers are under no 
>> obligation to give any definition to it.  When the standards fail to 
>> give a defined behaviour for something, the behaviour is again 
>> undefined.  It does not matter if this lack of definition is because of 
>> some "obscure" platforms, for optimisation purposes, for compiler 
>> simplicity, or an accidental omission in the text.  It really is that 
>> simple.
> 
> What matters, ultimately, is what compilers would need to do to process
> code in a fashion consistent with the purpose thereof.

You've got it ass-backwards.

Compiler writers write compilers that correctly compile code that is
written to the C standards.  It is the C programmer's job to write code
that is written to the C standards in order to use the compiler.

It is certainly /not/ the compiler writer's job to try to guess what
some C programmers might have meant when writing code that does not
follow the standards.

> 
>>> Most practical code would work "by happenstance" even with gcc.  On the
>>> other hand, a compiler which can't process the above code in accordance
>>> with what the Standard actually says should not be trusted to reliably
>>> process practical code either.
>>
>> Yes, clearly gcc is not a tool to rely on for compiling C.  The whole of 
>> the programming world should throw it out immediately.
> 
> The -fno-strict-aliasing dialect is processed reliably.  The
> -fstrict-aliasing dialect should not be trusted with code that may need
> the Effective Type of any object to change during its lifetime, even
> though the Standard requires compilers to support such code.  The rules
> as written are unworkable unless a compiler is willing to forego what
> should be useful optimization opportunities; gcc could be both simpler
> and better if it had a non-conforming mode for use with programs that
> don't need to change objects' effective types and a less aggressive mode
> that was willing to forego optimizations in exchange for being able to
> handle all required cases easily.

Back here in the real world, most code is compiled for gcc with
optimisation enabled and -fstrict-aliasing in effect.  You are simply
/wrong/ here.

> 
>> If you think that gcc is wrong, file a bug.  Smarter minds than yours 
>> will look at it and compare it to the standards, and see if the compiler 
>> needs to be changed.
> 
> Some bugs have been filed, but the fundamental problem is that the Standard
> is only designed to allow for a certain level of optimization but the
> authors of gcc are trying to go beyond what the Standard is designed for,
> rather than offering a mode that is documented as non-conforming, but which
> could be very useful for certain kinds of programs.

There you go again, imagining what you think the standard is designed
for, instead of looking at what it says.

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

Thread

Opinion sought: Is this strictly conforming C? lee@ansync.com - 2018-02-15 17:20 -0800
  Re: Opinion sought: Is this strictly conforming C? James Kuyper <jameskuyper@verizon.net> - 2018-02-15 22:15 -0500
    Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-16 08:44 -0800
      Re: Opinion sought: Is this strictly conforming C? jameskuyper@verizon.net - 2018-02-16 11:47 -0800
        Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-16 13:00 -0800
      Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:25 -0800
        Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 13:21 -0800
          Re: Opinion sought: Is this strictly conforming C? Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2018-02-19 15:26 -0600
          Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-19 13:59 -0800
            Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 14:38 -0800
              Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-19 15:21 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 15:59 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-19 17:11 -0800
                Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-20 09:17 +0100
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-20 07:58 -0800
                Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-20 18:21 +0100
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-20 09:25 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-20 11:52 -0800
                Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-20 22:27 -0500
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-20 23:07 -0800
                Re: Opinion sought: Is this strictly conforming C? Manfred <noname@invalid.add> - 2018-02-21 14:07 +0100
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 09:02 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 09:50 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 12:46 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 13:09 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 15:15 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 15:51 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 17:06 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 17:46 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 00:18 -0800
                Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 22:14 -0800
                Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 11:39 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 14:59 -0800
                Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-21 22:14 -0500
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 00:50 -0800
                Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-22 07:22 -0500
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 12:40 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-22 13:00 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 13:48 -0800
                Re: Opinion sought: Is this strictly conforming C? scott@slp53.sl.home (Scott Lurndal) - 2018-02-22 22:14 +0000
                Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 23:05 -0800
          Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 23:39 -0800
            Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-22 10:39 -0800
              Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 13:20 -0800
              Re: Opinion sought: Is this strictly conforming C? asetofsymbols@gmail.com - 2018-02-23 00:30 -0800
    Re: Opinion sought: Is this strictly conforming C? Manfred <noname@invalid.add> - 2018-02-16 20:05 +0100
      Re: Opinion sought: Is this strictly conforming C? lee@ansync.com - 2018-02-16 11:14 -0800
      Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 11:30 -0800
      Re: Opinion sought: Is this strictly conforming C? Steve Carroll <frelwizzen@gmail.com> - 2018-03-01 09:01 -0800
  Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 11:08 -0800
    Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 17:16 -0800
      Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 23:16 -0800
        Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 00:25 -0800
          Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-22 07:41 -0500
          Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:24 -0800
            Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-25 12:07 -0800
              Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-25 18:34 -0500
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-26 08:21 -0800
                Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-26 22:22 -0500
                Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-27 09:16 +0100
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-27 08:48 -0800
                Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-28 10:24 +0100
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-28 09:03 -0800
                Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-28 22:31 +0100
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-28 15:19 -0800
                Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-03-01 12:37 +0100
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-03-01 11:03 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-03-01 11:22 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 11:48 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 15:11 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 16:14 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 19:53 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 21:27 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 00:52 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 01:54 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 06:11 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-03-01 12:31 -0800
                Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-03-01 13:15 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 14:55 -0800
                Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 02:19 -0800
                Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 03:03 -0800
              Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-25 15:36 -0800
                Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-26 10:17 -0800

csiph-web