Re: Help. What is the error?

jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
> Kenneth Brody wrote:
> You need to include <stdlib.h> to get malloc's prototype.
>> Why does it fail on one system and work on another? Because that's
>> how "undocumented behavior" behaves.

As others have pointed out, this is probably a typo for "undefined
behavior".

> The code will work if the returned pointer lies in the first 4GB
> virtual memory space, it will crash if it doesn't.

Not necessarily. It could work on a 64-bit system if 32-bit and
64-bit types happen to be passed as arguments in the same way, or if
int, void*, and int* are all 64 bits. It could either succeed or fail
on a 64-bit system with a pointer in the first 4GB of the virtual
memory space depending on whether the system is big-endian or
little-endian. It could fail on either a 32-bit or a 64-bit system if
integer and pointer arguments are passed by different mechanisms, for
example in different registers. It could misbehave without actually
crashing on a 64-bit system if the truncated pointer value happens to
be a valid and accessible address. And so on.

The OP asked about 32-bit and 64-bit systems. He gave no clue about
which systems he was using, and it's unwise and unnecessary to assume
he meant, say, x86-32 and x86-64.

Undefined behavior is undefined behavior. It can certainly be useful
to discuss what the likely consequences are, particularly in
debugging, but all such discussions are system-specific and can only
be in terms of likelihoods unless you go down to a level of detail
that's inappropriate for this newsgroup.

You cannot correctly claim that the code "will work" in some
circumstances or "will creash" in other circumstances.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.

Relevant Pages

  • Re: Small C "Puzzle"
    ... > really see anything wrong with the code (yes, stdlib.h is missing, int ... In this case, the undefined behavior manifests ... invalid pointer value. ...
    (comp.lang.c)
  • Re: Question about void pointers
    ... That is undefined behavior by reason of trying to print an pointer ... unsigned int on many systems. ... Yes, but that difference has no portable meaning, and the ...
    (comp.lang.c)
  • Re: What does the standard say about array access wraparound?
    ... Note that the object you've named 'array' is ... *not* an array, it's a pointer. ... so evaluating it will produce undefined behavior. ... and 'len' should be of type 'size_t', not 'int'. ...
    (comp.lang.c)
  • Re: accessing freed memory without error
    ... it would try to dereference a null pointer. ... returns type 'int'. ... does not define such a conversion. ... which case you have more undefined behavior. ...
    (comp.lang.c)
  • Re: Making Fatal Hidden Assumptions
    ... int *p; ... say anything about the value of the pointer. ... for which this International Standard ... Once undefined behavior has occurred, ...
    (comp.lang.c)