Re: Thou shalt have no other gods before the ANSI C standard

websnarf_at_gmail.com
Date: 02/08/05 

Date: 7 Feb 2005 18:47:59 -0800

D. J. Bernstein wrote:
> Douglas A. Gwyn wrote:
> > The fact is, using calloc to initialize non-integer values is
> > *wrong*
> [...]
> I'll readily agree that the all-0-bytes representation of NULL isn't
> guaranteed by the C standard. I'll also agree that there was, once
> upon a time, an obscure C implementation that, for silly reasons,
> used a different representation of NULL.

Oh its worse than that -- there apparently exists exactly 2 platforms
which could use two different representations for a pointer depending
on their type. Because of these two platforms (neither of which has a
C99 compliant compiler installed on them -- and which never will) the
standard says you can't memcpy pointers, or assume the size of one is
the same as the size of another, etc.

> [...] But this doesn't mean that programs relying on the all-0-bytes
> representation are ``wrong.'' It simply means that they won't work
> with goofy implementations of C.
>
> > and every competent C programmer knows it

Do you like how he snuck in "competent" in there? He actually tried to
defend '\0' terminated strings as actually *higher performance* than
length delimited strings. Sorry, but I don't associate competence with
that sort of stupidity/denial.

> The vast majority of C programmers are writing code for PCs,
> Macs, Suns, etc., running Windows, Linux, MacOS, BSD, etc., all
> of which guarantee
>
> * an all-0-bytes representation of NULL,
> * 8-bit char,
> * 16-bit short,
> * 32-bit int (the 286 is dead), and
> * IEEE single-precision 32-bit float (UNICOS is dead),

You left out a really important one: right shifting of signed values
always results in sign extension. :) But seriously, you can't leave
2s complement off that list.

> among other things. Taking advantage of these guarantees is
> convenient for the programmer and doesn't sacrifice any real-world
> portability.

It is physically impossible for some people to parse and comprehend
that statement. I'm not kidding, the very concept of what you just
said is just far too abstract of an idea for these people to
understand. It is beyond their being.

2s complement, IEEE-754, 32bit ints is a defacto standard that has more
momentum than any language specification. That's why these important
functional attributes continue to exist even though the latest ISO C99
standard (which is 4+ years old now) has not been adopted by any major
vendor. The deafening silence with which the C99 standard has been met
by the industry is testimony to what the *REAL* standard is (POSIX +
the various system ABIs + the "32bit" features you listed above). 

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... But what is TSO? ... Technical Standard Order, a minimum performance standard issued by the FAA for certain ... have been more commonly referred to as the "cache coherency" ... A mutex is sufficient to guarantee visibility, ...
    (microsoft.public.vc.mfc)
  • Re: Segfault City
    ... Realizing ... What, if anything, can it be guaranteed will be> '9' in standard C? ... there /isn't/ any guarantee of a character greater than '9' in C. ...
    (comp.lang.c)
  • Re: Segfault City
    ... Andrew Poelstra wrote: ... What, if anything, can it be guaranteed will be> '9' in standard C? ... Perhaps I should have studied English more in high school at East ... there /isn't/ any guarantee of a character greater than '9' in C. ...
    (comp.lang.c)
  • Re: questions on ftell and fopen
    ... foo: ... actually guarantee that a failing fopensets errno. ... A standard is a contract between the implementer and the programmer. ...
    (comp.lang.c)
  • Re: questions on ftell and fopen
    ... actually guarantee that a failing fopensets errno. ... Since the standard doesn't guarantee that a failing fopendoes *NOT* ... A standard is a contract between the implementer and the programmer. ...
    (comp.lang.c)