Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Spurious diagnostic messages |
| Date | 2015-10-06 14:29 -0700 |
| Organization | None to speak of |
| Message-ID | <ln37xnlm7l.fsf@kst-u.example.com> (permalink) |
| References | (16 earlier) <kfnlhbh4wjj.fsf@x-alumni2.alumni.caltech.edu> <mutcah$tpt$1@dont-email.me> <929a5929-0a7e-4c01-9694-b2ee885c921f@googlegroups.com> <muvspj$svk$1@dont-email.me> <f12f739d-5b79-41fc-b37b-96c0c1cd4aac@googlegroups.com> |
supercat@casperkitty.com writes:
[...]
> 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.
Personally, I've worked on one platform that had no 16-bit integer
types, and another that had no 16-bit or 32-bit integer types. On both,
char was 8 bits and int was 64 bits. That was admittedly an unusual
case (Cray supercomputers), and I'm not necessarily saying you shouldn't
make that particular assumption. But it's not hard to imagine that
future systems might violate your assumption.
> 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".
long is usually 64 bits on 64-bit systems (apparently MS Windows is an
exception). I'm not sure how common such systems were prior to 1999.
If I needed exact 16-bit and 32-bit types and I was stuck with a pre-C99
compiler, I'd probably use Doug Gwyn's q8 or something similar.
http://www.lysator.liu.se/c/q8/index.html
> 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.
The standard defines a an "object representation" as a set of
unsigned char values; it can be obtained by memcpy(), for example.
I find that using unsigned char for raw byte values is conceptually
cleaner. I'm vanishingly unlike to have to use a system with signed
char using non-2's-complement with two reprentations for zero,
but by using unsigned char I don't have to think about it.
[...]
> 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.
That's probably a valid assumption for any system with a monolithic
memory addressing scheme. But I can imagine other schemes becoming more
popular in the unspecified future. A scheme where each allocated object
has its own disjoint address space could have some advantages.
[...]
> 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.
>
> 8. Left shifts of negative values will behave as multiplying by a power of
> two, with the same overflow semantics described in 6.
>
> 9. Right shifts of negative values will be performed using sign extension.
How difficult is it to avoid shifts whose behavior is not defined by the
standard? How useful is it be able to compute, for example, n<<32,
where n is of type uint32_t?
[...]
> 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.
Not, as far as I can tell, due to any changes in the language. (We've
discussed that at some length before.)
>> 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? 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 personally would oppose making binary constants an optional
feature. It would IMHO be worse than not adding them to the
standard at all. The cost of implementing them is so small that
I see no point in permitting compilers *not* to implement them.
The value of __STDC_VERSION__ would reliably tell you whether
they're supported (assuming a non-buggy compiler).
The cost of defining and documenting __STDC_BINARY_LITERALS is minor
for compiler writers, but it would IMHO be a wart on the language
and confusing to users.
C99 added hexadecimal floating-point constants and made them
mandatory for all conforming compilers.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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