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

Groups > comp.os.msdos.programmer > #1171

Re: Smaller C compiler

Show all headers | View raw

On Fri, 13 Dec 2013 06:32:43 -0500, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:

> It's not exactly up to the compiler.

Yes, it is.

The C specification doesn't specify the low-level implementation.
It's an abstraction of C from the implementation details.

E.g., see early Forth specifications for comparison.  They specify
much of the implementation.

If you want to learn about the expected way to implement C, you need
to read the C Rationale as well as original papers by Kernighan, Ritchie,
Johnson, et. al. on the subject.  At least two current versions of the
C Rationale are online as pdf's.  I've not been able to locate the original
rationale as pdf although I've been searching for it for many years now.
(See "Rationale for American National Standard for Information Systems
- Programming Language - C")

Dennis Ritchie's papers on C
http://cm.bell-labs.com/who/dmr/

> There are specific rules for different situations.

True.

But, there are also contradictions which are part of the standards.
This is because the original C89 standard was derived from working
C compilers which worked differently.

How do you resolve a contradiction? Both are required...

> And this one is not one of those.

C preserves values (required).  There is a type mismatch not fixed
by a promotion, conversion, or explicit cast.   The only way to
preserve the value is to cast it to the parameter's type.  When
this is done by the C compiler it's called an "implicit cast."
This is a logical result of the C specifications, i.e., allowed
by it.

> If you pass a char or a short to printf(), it will first get
> converted into an int (possibly unsigned) and only then will
> it be available to printf().

It must be converted to a type that preserves the value.
Preservation of an integer's value is a fundamental C principle
and required by the specifications.

> Likewise, if you pass a float to printf(), it will first get
> converted into a double and will be available to printf() as
> a double.
>

Yes, there are defined type conversions and promotions, but you're
getting too caught up in the rules of C syntax or semantics and
ignoring how real world C compilers are actually implemented.  You
can't expect everything to work exactly the way the C specification
describes.  That's open to interpretation anyway, and I've seen
quite a few self-proclaimed experts on comp.lang.c. describe things
incorrectly.


IMO, good C compilers have a fundamental set of principles they follow:

  1) integer conversions preserve the value (*)
  2) lossless conversions of pointers (*)
  3) operators work as expected, independent of limits.h or UB
  4) implicit casts convert mismatched types (**)
  5) that which fits best onto the native assembly shall be done

(*) required by C specifications
(**) result of C specifications

>> Also, on integer conversions:
>>
>> "If the destination type is longer than the source type, then
>> the only case in which the source value will not be representable
>> in the result type is when a negative signed value is converted
>> to a longer, unsigned type."
>>
>> Of course, the source type to "%04lx" is a 16-bit unsigned and
>> is converted to a unsigned destination type, likely longer.
>
> There's no destination type here. (Just like there's no stack.:)
>

Yes, there is.

The parameter to printf() for %04lx has a defined type.  It's defined
as: a pointer to an unsigned long, i.e., it's the address of the value
being passed as %04lx which must be of type unsigned long.  Dereferencing
the pointer to convert the value results in a type of unsigned long.

>> So, that and other similar statements in H&S are in the C
>> specification somewhere, most likely with different wording.
>
> I have not read or seen that book and I can't tell if it's
> misleading or just wrong

Are you joking?

Guy Steele Jr. was on the ANSI C X3J11 standards committee.

Guy Steele Jr.
http://en.wikipedia.org/wiki/Guy_Steele

Samuel P. Harbison
http://www.harbison.org/sph3/

Another former X3J11 committee member posts to comp.std.c.
His name is Douglas A. Gwyn.  He developed code for U.S.
Army's BRL-Unix.

Another former X3J11 committee member is P.J. Plauger of
Whitesmiths and Dinkumware and author of "The Standard C Library".

Another former X3J11 committee member is Larry Rosler.  He's
occasionally interviewed on C and C++ since he was an early
teacher of C and also knew Ritchie and Stroustrup.

P.J. Plauger
http://en.wikipedia.org/wiki/P._J._Plauger

> I've mentioned the relevant parts of the C99 standard.

No offense, but it's far more likely "you're not interpreting
[C99 standard] correctly," or even more likely, completely.
There are outcomes not explicitly stated in the standards.
E.g., if the C standards committee hadn't remove implicit
ints from C99, would you have even known there was a conflict
between implicit ints and typedef's in C89 by reading C89?
No, you wouldn't.  Yet, it's right there in the language grammar.

> It's a click away:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/standards.html:

I have copies of C89, C99, and numerous drafts as pdfs.
I also have the C Rationale as a pdfs.  I also have C89 and
the C Rationale in book form from before the modern pdf era.

> The conversion mentioned in the quoted bit of the standard is the
> conversion of the captured numerical or pointer type (long if %ld,
> int if %d, void* if %p, etc) into printable text.

That would print the pointer, not the integer value.

> It's not the intermediate conversion of int to long,

That's needed to pass the parameter correctly.

> While I have written lots of poor code, I have also learned from some of
> those mistakes. I'm avoiding UB by not triggering it, not by artful
> camouflaging of questionable actions. UB is not a fate. You can choose
> to have it or not.
>

You seem to be conflating UB with having a coding error.  They're not the
same.  UB doesn't mean you have a coding error.  It only means the
C specification doesn't define what happens in that situation.  The  
compiler
can and does define what happens.  In many cases, the behavior is well
defined and widespread, e.g., use of pointers to access specific memory
locations, or equivalence of pointers between various types the C  
specification
doesn't require.  The original C89 specification was derived from actual
implementations of C on various computing platforms.  So, there are a
number of very well defined situations for all microprocessors which
nearly all C compilers implement that is officially UB.  Why?  Because
mainframes and certain CPUs don't support that functionality.
Microprocessors since 1974 do though.  So, it's basically never going to
cause an issue to use such functionality in the majority of C code since
the machines where UB exists are obsolete and dead.

> http://stackoverflow.com/questions/20343190/evaluating-accessing-a-structure.
>

 From the code, I'm not sure if it's an issue with 'volatile', optimization,
or re-use of the variable name 's' which could be an issue.  What happens
if you change one 's' to a 't'?

Personally, I only use volatile in *two* very specific situations
which _generally_ work...

> I avoided UB in those shifts technically and legally. Period.
>

You're not responsible if the assembly is incorrect and the code
fails?  Tell your employer *that* someday.  I dare you!  ;-)

> You have your own ideas how things should work

That's true.  Mine matches the reality of actual C compilers,
as well as the numerous books on C that I learned from, as well
as the primary book on C that I still use: Harbison and Steele's
"C: A Reference Manual", 3rd. ed. 1991.

> and they don't quite match those expressed in the language standard.

That's true too.  No C compiler complies with the language
standard entirely.  It can't.  There are too many contradictions
and too many unecessary limitations.  C99 obfuscates the actual
meanings even further, compounding the issue.

My understanding of C corresponds very well with at least one
former member of the X3J11 committee since I've read what he
has written and also discussed C with him.  It's more likely my
view on C corresponds to three X3J11 committee members since
I have and use books by the other two.

> You may be finding holes and contradictions in my statements
> all day long until you've learned enough of standard C.

I started programming in 1981.  I've been programming in C since 1991.

I have a library of C books, probably thirty or more of them (packed
away now), all of which I read and learned from once.  Of all those
books, only two are of any value, IMO.  Harbison and Steele's
"C: A Reference Manual" and P.J. Plauger's "The Standard C Library".

>> Let's start over.
>
> Let's not. You have something to read and think through.

No, I don't.

I think you have much to learn yet, and eventually forget the
unimportant stuff, which you currently think is important.


Rod Pemberton

Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 08:15 -0800
  Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-01 18:42 +0000
    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 19:14 -0800
      Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-02 11:13 +0000
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 03:21 -0800
          Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 06:21 +0000
            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 23:17 -0800
              Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 13:31 +0000
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 06:05 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 10:47 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 21:18 -0800
  Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 12:23 -0500
    Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 16:26 -0500
      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 23:58 -0800
        Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:31 -0500
          Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 05:01 -0500
            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 02:20 -0800
              Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:33 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:37 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 12:19 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 22:23 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-07 13:48 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-07 16:34 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-08 02:12 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-13 03:32 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 04:47 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-15 02:14 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 13:21 -0500
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:39 -0800
            Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:38 -0500
              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:40 -0800
              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 04:19 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 13:40 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-14 21:07 -0800
    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 22:22 -0800
      Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:30 -0500
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:21 -0800
          Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 04:23 -0500
            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:31 -0800
  Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 04:59 +0000
    Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 06:17 +0000
      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 02:36 -0800
        Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-11 13:44 +0000
  Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-10 10:41 -0800
    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 03:06 -0800
      Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 10:47 -0500
        Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-11 08:01 -0800
          Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 13:40 -0500
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 22:07 -0800
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-25 02:33 -0800
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 03:24 -0800
  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-21 15:55 -0800
  Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-29 17:16 +0000
    Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 21:54 -0500
      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:38 -0800
    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:36 -0800
      Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-30 05:07 +0000
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 21:58 -0800
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-05 19:43 -0800
          Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-06 15:27 +0000
            Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-06 19:51 -0500
              Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-07 04:27 +0000
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-06 21:52 -0800
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-16 22:57 -0800
            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-25 00:17 -0800
              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-01 21:31 -0800
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-10 01:46 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-20 20:19 -0700
                Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-23 11:20 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-23 11:41 -0700
                Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-25 06:08 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-09-14 03:06 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-09 03:26 -0800
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-28 04:06 -0800
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-12-21 01:56 -0800
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-01-10 10:37 -0800
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-19 23:55 -0700
                Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2015-04-22 06:13 +0000
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-22 00:12 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-25 21:11 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-16 17:49 -0700
                Re: Smaller C compiler "Bill Buckels" <bbuckels@mts.net> - 2015-05-19 20:01 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-19 18:18 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:13 -0700
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:55 -0700

csiph-web