Re: Null pointers in C---spec (N869) trouble, was What computer language is used a lot in the IT industry?

From: Chris Torek (nospam_at_torek.net)
Date: 07/03/04 

Date: 2 Jul 2004 23:07:49 GMT

In article <news:NyfFc.1217$KK4.686@nwrdny02.gnilink.net>
Thomas G. Marshall <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>
writes:
>How is malloc() itself written then when it needs to coordinate throughout
>the heap?

I find this question quite confusing. What "heap" do you mean?
Coordinate with what other agent(s)? One can write memory allocators
in C, and they can use heaps, queues, AVL trees; first-fit, best-fit,
etc.; the details are up to whomever writes the allocator.

On the other hand, malloc() itself can *not* be written in Standard
C, for the simple reason that malloc() is required (by the Standard)
to provide "properly aligned" memory for *any* purpose, and there
is no Standard-provided way to discover or create such alignment.
So malloc() itself, if written in C, is necessarily written in
not-strictly-portable C. (I find this rather irritating myself,
and believe the Standard could have required implementations to
provide some macros and/or functions that, together with C99's
intptr_t, would do the trick.)

>Can it be called C?

It can be called Gronklezeeb, if you prefer. :-) I suspect you mean
"should" it be called C -- which gets into a rather different
problem, that of communicating ideas from one human being to another.
This is not something the C language, nor any Standard, can solve.

>If not then we have a problem: I want to quiz someone on their knowledge of
>what a C program will do [on, apparently, a specific machine or set of
>machines], not on what's called defined behavior in the spec.

In that case, ask that. But if you are posting in comp.lang.c, be
aware that machine-specific answers are considered off-topic, in
part because the answers *change* from one machine to the next.
The output from the "%p" format is quite different on the IBM AS/400
than on the average 32-bit system today (e.g., x86-based, using a
compiler like GCC and libraries like those included with Windows
or Linux or BSD). The pointers and perhaps even the integers
themselves are quite different as well. A Univac 1100 uses ones'
complement arithmetic and 9, 18 and 36-bit integers; a Tandem or
Eclipse has multiple pointer formats; and so on.

Apparently Arthur J. O'Dwyer <ajo@nospam.andrew.cmu.edu> wrote:
>> And no quiz on C
>> should assume *implicitly* that the quizzee thinks sizeof(long)==4.

>It's established by me in the begining, as I posted.

This is fine, but once you do it, you are no longer talking about
C-the-programming-language-for-the-abstract-machine-in-the-standard,
but rather C-as-used-on-the-Fooblatz-42. The knowledge required
is some combination of *both* "Standard C" and "Fooblatz details".

[And, apparently a different subject; it is again not quite clear:]

>take a look at N869 3.18:
>
>3.18
>1 undefined behavior
>behavior, upon use of a nonportable or erroneous program construct, of
>erroneous data, or of indeterminately valued objects, for which this
>International Standard *imposes no requirements*
[...]
>When 3.18 #1 says that undefined behavior can be behavior for which this
>standard imposes no requirements, is that suggesting that there are no
>requirements for that issue. That null pointer incrementing is simply free
>of requirements?

Correct. The C standard imposes *no* requirements. Any given
implementation can do *anything*, or even *nothing*. Whatever it
does or fails to do does not change its "conformance status".
Most compilers do "whatever is convenient" in problem cases, and
that is just fine, because ANYTHING they do is just fine.

Note that undefined behavior has *two* functions, as I outline in
<http://web.torek.net/torek/c/index.html> and
<http://web.torek.net/torek/c/compiler.html>. Without something
like undefined behavior, Standard C would not only be what you got,
it would be all you could *ever* get -- which would make C far less
useful in the real world, where one often needs to do something
that only works on Machine X, in some cases precisely *because*
it only works on Machine X.

>I'm crossing this over to comp.lang.c so they can beat this up as well. For
>those in c.l.c, the initiating concern is over the following interview
>question of mine:
>
> What does the following C snippet produce on a
> "normal 32 bit system". That is, 32 bit longs, byte
> addressable 32 bit address space, etc., etc. A
> sparcstation 1 for example IIRC---no tricks, nothing
> hidden. If there's a typo, I'm sorry, I'm typing this quickly.
>
> long *a = 0;
> long *b = 0;
> a++;
> b++; b++;
> printf ("%d %d %d\n", a, b, (b-a));

This requires knowledge, but not so much of C, but rather of "a
sparcstation 1 for example". Try this code snippet on an IBM AS/400
and see what happens. :-) What would you do with a candidate who
knows C quite well but has *only* used an AS/400?

Incidentally, the above code can even fail -- print bizarre
apparently-garbage results, in this case -- on 68000-based systems,
if the C compiler chooses to pass pointers in the "A" registers
and integers in the "D" registers. The printf() call would fill
in four A registers, and then the printf() engine would read out
one A register -- for the format -- and three D registers, for the
three %d directives. (I know of no 68000-based systems that pass
parameters in this way, but I do know of one that *returns* pointers
in A0 and integers in D0. This makes "failure to declare malloc()"
result in "program crashes mysteriously", even though the same code
works on the same machine if you use a different compiler suite.) 

-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: forget about it   http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Relevant Pages

  • Re: Null pointers in C---spec (N869) trouble, was What computer language is used a lot in the IT ind
    ... malloc() itself can *not* be written in Standard ... for the simple reason that mallocis required (by the Standard) ... The pointers and perhaps even the integers ... and integers in the "D" registers. ...
    (comp.lang.c)
  • Re: Garbage collection
    ... C standard conformance. ... Storing pointers on disk is not the only case I mentioned. ... I think the point about malloc vs. gc_malloc ...
    (comp.lang.c)
  • Re: Another question related to pointers.
    ... >>> From my understanding of pointers, a pointer SHOULD NOT BE ABLE to ... >> If C can't do this how are you supposed to write a malloc function in C ... >> (for example the gnu malloc)? ... > standard C. (I assume the standard C libraries provided need not be ...
    (comp.lang.c)
  • Re: sizeof(ptr) = ?
    ... Pointers of any type will have the same size because they hold the ... On standard PC's this is a 32bit address (4 ... Could you explain how malloc works for such systems please. ... But we are talking about values of "special memory blocks" where the ...
    (comp.lang.c)
  • Re: malloc under linux
    ... It means what it says, i.e., even if malloc returns a non-null ... memory might not actually be allocated. ... Standard even when some other process is killed and sufficient memory is ... I can't see how the Standard does not permit lazy allocation, ...
    (comp.lang.c)