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

Groups > comp.lang.c > #72120

Re: Spurious diagnostic messages

Show all headers | View raw

On 06/10/15 20:18, supercat@casperkitty.com wrote:
> On Tuesday, October 6, 2015 at 2:23:41 AM UTC-5, David Brown wrote:
>> On 05/10/15 19:06, supercat wrote:
>>> Brilliantly said.  I would further suggest that there are other aspects of
>>> the language where the principle applies even more strongly.  Some people
>>> seem to have an attitude that C programmers should in most cases try to
>>> write code that would be guaranteed to work on any standards-conforming
>>> compiler for any architecture, no matter how obscure.  I would posit that
>>> such an attitude is unrealistic and harmful.
>>
>> While I obviously agree with the first part of that paragraph, I am not
>> so sure about the rest.  There are many types of C programmers, and they
>> work in many different ways for different end-uses.  There are people
>> who write code that will be used on a wide variety of systems - often
>> they don't know what those will be while they are writing their code.
>> Sticking to the standards and avoiding any extensions or
>> implementation-defined behaviour (and perhaps even avoiding any standard
>> behaviour that they know is not implemented in some common compilers -
>> such as C11), is vital to such work.  And there are others who know
>> /exactly/ what tools will be in use - when I do an update on a 10-year
>> old project, I do so using precisely the same tools as I did 10 years
>> ago.  Most programmers will lie somewhere between those extremes.
> 
> My philosophy over the years has been that it is reasonable for most kinds
> of code to assume:
> 
> 1. It will never be called upon to run on any platform which does not have
>    non-padded two's-complement and unsigned 16-bit and 32-bit integer types
>    available which are stored either big-endian or little-endian format,
>    but code should not make assumptions about *which* absent a good reason
>    to do so.

Agreed.

> 
> 2. Prior to C99's definitions for int16_t, int32_t, etc. the closest thing
>    to standard names for 16-bit and 32-bit types were "short" and "long".
> 

I sort of agree - but if I use a pre-C99 compiler that doesn't have
<stdint.h> (and I do have old projects with such compilers), then I make
my own "stdint.h" with appropriate typedefs.  The compiler-specific
parts are therefore kept to a minimum.


> 3. Writing to an object of a particular type is equivalent to overwriting
>    the underlying "char" values with that type's "char[]" representation,
>    except that types which contain padding may arbitrarily decide to copy
>    the padding or leave it alone.
> 

Agreed.

> 4. Reading an object of a particular type is equivalent to reading the
>    underlying "char" values and interpreting them as the type in question.
> 

Agreed.

> 5. Comparisons between unrelated pointers abide by the rule that if char*p
>    is a pointer to an object of size s, and char *q is any pointer,
>    the expression (q>=p && q<p+s) will yield one whenever q identifies part
>    of p, it will likely (though not necessarily 100% reliably) yield zero
>    when q does not identify part of p, and will never do anything other
>    than yield zero or one in any case.

Mostly agreed.  I have some targets where pointers to data in flash are
unrelated to pointers to data in ram (since access to flash and ram use
different cpu instructions), which makes some pointer handling more
complex.  The simple workaround is, of course, never to make comparisons
between these different types of pointers - then the issue doesn't arise.

> 
> 6. In the absence of absented documentation to the contrary, arithmetic
>    overflow on integer types will yield a Partially-Indeterminate Value
>    with the semantics that every rvalue conversion will yield a number
>    which is congruent to the arithmetically correct value modulo the
>    range of the type, but might not necessarily be within the range of
>    the type.  If such a value is stored in a variable, repeated rvalue
>    conversions may yield different values subject to that constraint.

Disagreed.  Compilers may make use of the undefined behaviour here for
optimisation purposes.  I think it is safe (for the same sense of "safe"
as the rest of your rules) to assume that in a calculation, integer
overflow will be done as simple wrap-around for two's complement
arithmetic, since that will be the shortest and fastest implementation
in almost all circumstances.  But any clear reliance on this behaviour,
such as using "if (x < 0)" to attempt to check for overflow, is wrong.
You can, however, rely on the compiler not inserting additional checks
such as "if (overflow) launchNasalDaemons();".

> 
> 7. The expression, x<<y, when y>=INTSIZE, will yield either
>    x<<(y & INTSIZE) or x<<(y-1)<<1, chosen in unspecified fashion;
>    right-shifts will behave likewise.

Disagreed (as above).

> 
> 8. Left shifts of negative values will behave as multiplying by a power of
>    two, with the same overflow semantics described in 6.
> 

Disagreed (as above).  Do your multiplies as multiplies, and let the
compiler turn them into shifts.

> 9. Right shifts of negative values will be performed using sign extension.
> 

Disagreed (as above).  Also, some platforms have only logical right
shift instructions - implementing sign-extended behaviour would be costly.


> I know of very few cases where where straightforwardly-generated code which
> targets a modern machine, would work in cases mandated by the C Standard,
> and would behave consistent with the above behaviors 1-9, would be any more
> expensive than the optimal straightforwardly-generated code which was not
> required to abide by 1-9, and I until recently the default behavior of
> every compiler I've used (and I've used quite a few, for a wide range of
> platforms) would be to uphold the above guarantees even in those rare cases
> where it might require an extra instruction or two (e.g. on processors
> without an arithmetic-right-shift instruction).
> 
> IMHO, there is no good reason why the above behaviors should not be
> recognized as common extensions, which should be supported in the absence
> of a compelling reason to do otherwise.  

To be of any use (i.e., to be something that developers can rely on),
these would have to be a fixed set of rules - a "normal system"
extension.  It would be important that any C system supporting this,
support all aspects of it - if you allow some parts to vary according to
"compelling reason", you might as well stick to the current
implementation defined behaviour.  The point here would be to define a
set of "normal" implementation-defined behaviour rules, along with
making some undefined behaviour be defined.

I would be happy to see something along these lines become an official
extension - not part of the main C standard, but overseen by an ISO
group.  (An extension for embedded systems, including 0b binary
literals, has been mentioned.  The two extensions here would be orthogonal.)

> Being *explicitly* told by a
> programmer "this section of code does not require certain commonly-provided
> guarantees" would be a compelling reason.  The fact that a particular
> hardware platform would make code which upheld a certain guarantee 50%
> slower than it would have to be otherwise could be a compelling reason.
> The theoretical possibility that it might be possible to make some code
> meet its behavioral obligations more quickly would not be such a compelling
> reason.
> 
>> If the compiler I am using for a project provides useful extensions, I
>> will use them when they make a difference.  Some of my code is reused
>> between projects with different tools - for such code, unusual
>> extensions should be avoided (or hidden behind macros).  But much of it
>> is either project specific, or will be re-used in projects with similar
>> tools - extensions then make sense.  As a small systems (bare bones)
>> embedded programmer, my programs /always/ need at least some sort of
>> extensions or tool-specific code for hardware interaction, embedded
>> assembly, interrupt handling, etc.
> 
> Have you used any platforms which would have any difficulty meeting any of
> the above guarantees?

Yes, for some of your list - as noted above.  That applies both to
compilers that don't follow your list, and platforms that make it hard
or inefficient to do so.

>  Some platforms would be able to offer useful
> guarantees beyond the above (e.g. some will allow code to test for object
> overlap without any false positives, though e.g. some 8086 compilers will
> not).  Code which relies upon the guarantees above can in many cases be
> clearer than any comparably-efficient code which does not (if comparable
> efficiency without those guarantees is even possible).
> 

While I am not convinced by all of your list, I certainly agree that
sometimes target-specific code that makes use of known
implementation-defined behaviour can be clearer, neater, and more
efficient than code that avoids any implementation-defined behaviour.  I
make use of such code, balancing the potential benefits of portability,
the likelihood of differences in implementation-defined behaviour, and
the benefits to the code at hand.  As a simple example, I make heavy use
of uint8_t, even though it does not exist on all platforms.

> While it may be useful to be able to use hardware that cannot efficiently
> offer those guarantees to run programs that don't require them, I see no
> reason to believe that future hardware will be any less capable of honoring
> them than present hardware.  While I recognize that the value of assumptions
> about what things will or won't alias, the rules about type-punning are
> simultaneously insufficient to identify most cases where a compiler could
> safely and usefully assume things won't alias, but so restrictive as to
> preclude many useful programming techniques.
> 
>> But I make a point of avoiding relying on implementation dependant
>> behaviour for "normal" C code.  Even if I know the code I am writing
>> will only ever be run on this particular 16-bit microcontroller, I'll
>> use int16_t rather than int when I want a 16-bit integer.  I always know
>> if my target is little-endian or big-endian - but any code that depends
>> on that difference will be minimised, and well commented.
> 
> My point is that behaviors like those listed above should not be considered
> "implementation-dependent".  C is the only language I know of in which the
> set of "safe" behaviors has decreased rather than increased over the last
> decade.
> 
>> Binary literals are already implemented on most compilers targeting
>> embedded systems.  In most cases, they use the 0b format - but there are
>> some exceptions for toolchains that had implemented binary literals
>> before 0b became the de facto standard.  However, these are mostly for
>> smaller and more painful microcontrollers, and code written for such
>> devices is typically very highly specialised to the microcontroller and
>> compiler.
> 
> Do you know of any situations in which different compilers that accept 0bXXX
> literals would not interpret them the same way, or can you think of any
> reason why a compiler would want to?

No (baring possible bugs in implementations).

>  If not, what disadvantages would you
> see to having a Standard indicate that implementations which define a
> certain macro (e.g. __STDC_BINARY_LITERALS) with a non-zero value are
> required to interpret literals of that form the way that existing
> implementations do?  The only costs imposed by such a rule would be:
> 
> 1. Compilers which implement such literals should add a predefined macro
>    indicating that.
> 
> 2. Compilers which don't implement such literals must refrain from using the
>    identifier __STDC_BINARY_LITERALS for some other purpose.
> 
> Cost #1 seems pretty small, and cost #2 negligible.
> 

/I/ see no problem with just adding 0b binary literals to the standard
for the next version of C.  But I understand that other people /do/ see
it as a problem.

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

Thread

Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-29 08:55 -0700
  Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-09-29 10:22 -0700
    Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 23:42 -0700
      Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-05 09:41 -0700
        Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 13:22 -0700
  Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-09-29 22:28 +0200
    Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 00:14 -0700
      Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-05 10:30 +0200
        Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-05 10:06 -0700
          Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-06 09:23 +0200
            Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-06 11:18 -0700
              Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-06 14:29 -0700
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-06 15:33 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-07 12:35 +0200
              Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-07 10:57 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-07 07:09 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 09:28 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 01:45 -0700
                Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-08 09:42 +0000
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 09:42 -0700
                Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-07 09:40 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 09:44 +0200
                Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-08 08:25 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 20:36 +0200
                Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-08 13:28 -0700
                Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-08 22:21 +0100
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 14:33 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-09 10:24 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-09 08:35 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-11 15:18 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-11 14:53 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-12 09:17 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-12 00:37 -0700
                Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 00:31 -0700
                Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-10 10:50 +0100
                Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-10 11:01 +0100
                Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 03:43 -0700
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:26 -0700
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:34 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-11 15:25 +0200
        Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-14 07:43 -0700
          Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-14 17:00 +0200

csiph-web