I tried to explain the power of the pointer to them but I fear that most of them never got it. Your succinct explanation here, though, probably would have helped them understand.

Cheers, coming from HN.

(Oh, and the “const” shouldn’t be there. The standard specifies two forms for the definition of main; neither of them uses “const”. It’s unlikely to cause any problems.)

I once had an interview question involving the output of a program that involved something along the lines of “i = i++;”. I said the behavior was undefined. The interviewer insisted that it’s well defined. Another answer, of course, is that the line will never survive a code review; whatever it’s supposed to mean, there’s a better way to say it. (I got the job.)

char str [] = "Hello, world";

and in main.c:

extern char *str;

int main (int argc, const char *argv [])
{
     printf ("str is '%s'\n", str);
     return 0;
}

Q: what will happen when the resulting program is run, and why?

You’re referring to defined limits of precision in the standard.

You cite a rather interesting case where short is padded but int is not.

There are ranks for precision of conversion that must be met in the standard as well requiring that the highest rank is long long, followed by long, followed by int, followed by short, and lastly char.

That said, you have to be able to represent the numerical value of a short in an int… your example of padding digits is one I’ve never seen happen, but I suppose it could, and thusly could increase the size of a short, but the size would then not be an indication of precision

My main point is, knowing the LP32, LP64, ILP64 or whatever model of the system in question, is pretty much a prerequisite to doing useful things with integer types, and stdint.h is a nice portable way to get some of the behavior you want, when portability matters.

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
==========

That’s not *quite* true. The standard makes certain guarantees about the *ranges* of the predefined types. It guarantees that sizeof(char)==1, but you could conceivably have sizeof(short) > sizeof(int) (this would require short to have padding bits, i.e., bits that don’t contribute to the value). In practice, the above size relationships will almost certainly hold.

Some more guarantees:
sizeof(char)==1
The range of each type in the following list is a subset of the range of the following type:
signed char, short, int, long, long long
Likewise for the corresponding unsigned types. (Plain char has the same range and representation as either signed char or unsigned char, but is a distinct type.)
char is at least 8 bits
short and int are at least 16 bits
long is at least 32 bits
long long is at least 64 bits
(Those guarantees are actually stated in terms of ranges.)

Pointer objects are allocated wherever you happen to allocate them. The memory that a pointer *points to* is typically allocated on the heap, but you can easily have a pointer point to an object that’s allocated anywhere you like.

The C++ “new” operator very likely is implemented using malloc(), but that’s not specified by the language. This is an important distinction; allocating with “new” and deallocating with free(), or allocating with malloc() and deallocating with “delete”, might happen to work, or it might go badly wrong.

calloc() does not allocate on the stack; it’s like malloc() except that the allocated memory is initialized to all-bits-zero. You’re probably thinking of alloca() (which is non-standard and generally not recommended).

Any object can be allocated anywhere (or, as the C standard puts it, with any storage duration: static, automatic, or allocated). Pointers and arrays are just two particular kinds of objects; others are integers, floating-point objects, structs, and unions. The way a particular object is allocated depends entirely on the code used to create it.

Incidentally, the C language standard doesn’t use the terms “stack” and “heap”.