Slashdot Mirror

Incidentally, C is even better: because you can move the pointer

You can sort-of simulate an array using pointers, but this is one of the misconceptions people have about C: an array name is not a pointer.
A pointer is a variable that holds an address, and an array name is not a variable.

http://c-faq.com/aryptr/aryptrequiv.html

No. You are confusing dereferencing a null pointer, which is in fact undefined, with checking a pointer for null which is 100% defined. Read the comp.lang.c FAQ null pointer section for a better understanding of where you went wrong.

It's so easy to stray into undefined behavior with C. The language is full of gotchas. Sure, the tip of the iceberg could fit on a notecard or two, but the messy details sure as hell won't. They have whole FAQs for that: http://c-faq.com/.

printf("yes");

That one simple statement actually does a LOT of stuff.

Not really, it just passes a pointer to a string as vararg to a function named "printf". There's not much complexity in that statement. The printf function may be complex, but that's why it's in a standard library -- so programmers don't need to reinvent the wheel every time they need to do some common task.

The % operators are hellish to get just right (unless you do not mind memory over/under runs). Many implementations get something as simple as

short xyz = 1;
printf("%d", xyz);

Results in a memory overrun in many versions of printf.

right way is
printf("%h", xyz);

That is but one example of something complex that is simple to write that is hard to get right.

Aren't short's in a vararg supposed to be automatically promoted to int's by the compiler (and floats to doubles)? If this is true, then sounds like this case isn't "hard to get right", it's just plain wrong and will likely cause problems with every function that accepts varargs.

This is wrong. == is not a sequence point and the result of C++ == C is undefined.

I suppose I can respect that you don't think it's a problem worth solving. But I think that if you're going through all the trouble of designing a new language, you might as well fix as many problems as you can, no matter how small. Certainly compound declarations with function pointers are complex, but I think the ability to read the declaration from left to right is a major improvement over the Clockwise-Spiral Rule of C.

Which must be either "0" or "(void *) 0". ...
There are indeed some platforms where a null pointer is not an all-bits-zero value, but this is achieved by compiler magic behind the scenes. It is still created by assigning the constant value 0 to a pointer, and can be checked for by comparing a pointer with a constant 0.

What you've said is technically true, but doesn't contradict or clarify the post to which you replied in any way, so I'm not sure what your point is.

As you point out, a NULL pointer is a pointer which is represented by "(void *) 0" in the C language. However, where you may be confused is that "(void *) 0 != (int) 0". At least, not always. The compiler is responsible for determining if any "0" is used in a pointer context and casting it to the appropriate value, which may not be the same as numeric "0". So, while it's always possible to check for a NULL pointer by comparing a pointer to 0 in code, the machine may use a different value for NULL pointers. When you check "if(p)", the binary code that is produced will be comparing the value of "p" to the NULL address which is appropriate for the machine on which it is running.

The C FAQ has more information.

Datagrid or not, if your site requires flash for anything other than playing sound or video files, then it is more than likely I will not spend much time there

Absolutely. And it is not just for being unavailable to disabled people, slow, insecure, buggy, destroyer of the control a user has about the navigation (top-of-the-head example: if a menu is implemented in flash, how do you choose whether to open a menu entry in a new tab or new window?), bandwidth-wasting, proprietary, restricted and not class-platform; it is also about the content.

There is a very strong negative correlation between the usefulness of a site and the amount of bling in it.

https://www.cia.gov/library/publications/the-world-factbook : no Flash; javascript unnecessary
http://www.c-faq.com/ : no Flash; no javascript
http://news.google.com/ : no Flash ; javascript not necessary
http://news.bbc.co.uk/ : Fash restricted to the videos ; javascript unnecessary

Now compare this to a typical teenager-oriented website: even menus are Flash. They choose Flash both
for things that make 0 sense being flash (like menus) and for things that may be easier with Flash, but are almost always a big waste of time. They think a website needs to animate every other element.

The one positive aspect in Flash is that it its use warns you against the quality of the content before you waste your time loading and reading it.

I think you're looking for something like this list here.

Just out of curiosity sake, although the standard allows NULL pointer to have storage other than zero, is there any real world compiler where this is true?

Read this

If so, it would break most code that uses unions with pointers for storage (i.e. load-in-place fixups) and code that relies on extra bits and bit-patterns shared with pointers (i.e. lots of lockfree code stuffs data into what is assumed to be unused bits in pointers). It would probably break a lot of code that uses pointer math as well -- for example, anything using an "offsetof()" style macro.

I don't see why a non-zero NULL would break any of that, especially the offsetof() thing?

NULL has always been implementation defined. The whole reason why the macro was put into ANSI C was to move people away from the practice of casting a 0 into a pointer as was done with K&R C. While rare today, there have been commercial computers that didn't use 0 for the null address. The comp.lang.c FAQ lists some of them.

Stroustrup's unwillingness to implement a null keyword is the biggest single flaw in C++. It's pretty silly to pepper your code with magic 0's when the compiler could very well be changing them to something else if the target platform uses a different convention for nulls. It completely flies in the face of the type safety mechanism in C++ to have this sort of automatic conversion of a literal integer into something else that is decidedly *not* an integer.

Considering all the cruft that has been bolted onto C++, it's really annoying that B.S. couldn't see the wisdom of having a "null" keyword (or "_Null" a la C99 "_Bool").

Actually, in C the null pointer constant is a distinct value from integer zero. The standard requires the following (see section 6.3.2.3 of ISO C99):

• That the integer value 0, when cast to any pointer type, yield a null pointer
• That a null pointer, when cast to any other pointer type, yield another null pointer
• That any two null pointers will compare as equal, regardless of type

As for constructions like if (!ptr), the standard requires that the if statement execute if its value is non-zero, and it would be entirely legal for the null pointer to have a non-zero in-memory representation, but convert to the integer zero. See, for example, the comp.lang.c FAQ.

If there is one thing I'll complain about, it's the choice of the value 0. It's almost impossible to trace it. When we do hardware debug of chips, we prefer to use a much more visible value such as 0xdeadbeef for instance. Otherwise a bad pointer will bland too much with all the uninitialized values out there.

There's nothing stopping a C compiler from using 0xDEADBEEF for the internal representation of a null pointer. The fact that 0 can be a null pointer constant in the source text isn't an issue.

Wrong. A NULL pointer is implementation-defined in C and !p would work just as well if the bit value of p were 0xdeadbeef for a NULL pointer. The compiler is responsible for that.

0 is used because it's convenient for compilers and architectures, not for programmers. Programmers don't care, they never see the bit pattern of a NULL pointer unless they're doing things wrong (casting to integers) or working on lower level architecture-specific code. Most think they do, though. See the C-faq section on NULL pointers.

The C specification already requires the compiler to deal with that, and it's been the case since K&R. No matter what the implementation defines as NULL, comparing or assigning 0 in a pointer context always works.

http://c-faq.com/null/ptrtest.html

What about Steve Summit's FAQS?

See the FAQ: http://www.c-faq.com/decl/initval.html

It includes section references, if you want to look at the standard. (It simply says "ISO" which I would guess refers to C89.)

Statics (including functional-local statics) and globals are initialised to zero, including structure members, in the absence of an explicit initialiser. This means integer types have the value zero, floating point types have the value 0.0 (even if that representation is not all zero bits), and pointer types have the value NULL (even if that representation is not all zero bits).

You are right that some systems don't initialise all those variables to zero (I've used such systems, long ago). There are also systems which initialise them to all-zero-bits, which is not the same as 0.0 floating point or NULL, on some systems.

To the best of my knowledge, neither of those are conformant C89, C99, or even K&R. I'll freely admit I may be wrong (I never read the whole of either standard), but I'm inclined to trust the comp.lang.c FAQ, which gives references to sections of the ISO standard.

I can't think of any language or system offhand in which NULL implies zero. What are you referring to?

Welcome to the world of Floating point arithmetic.

Look at these articles.

http://support.microsoft.com/kb/q78113/
http://c-faq.com/fp/printfprec.html
http://c-faq.com/fp/fpequal.html

Microsoft Excel was designed around the IEEE 754 specification with respect to storing and calculating floating-point numbers.

Welcome to the world of Floating point arithmetic.

Look at these articles.

http://support.microsoft.com/kb/q78113/
http://c-faq.com/fp/printfprec.html
http://c-faq.com/fp/fpequal.html

Microsoft Excel was designed around the IEEE 754 specification with respect to storing and calculating floating-point numbers.

Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression.

i = v[i++]; // the behavior is unspecified

Because programs rarely return memory to the OS when they free it internally. See here. Try changing the pref (as described elsewhere in this thread), restarting Firefox, and watching its memory usage then.