Domain: c-faq.com
Stories and comments across the archive that link to c-faq.com.
Comments · 22
-
Re:MatLab eh..
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. -
Re:Null pointer detection at compile time
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.
-
Re:Big difference here . . .
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/.
-
Re:interesting topic, disappointing article
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.
-
Re: C++ is not equal to C
This is wrong. == is not a sequence point and the result of C++ == C is undefined.
-
Re:Added value of Go?
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.
-
Re:Wait, what?
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.
-
Re:My Kingdom for a Datagrid Element!
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 unnecessaryNow 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.
-
Re:null or not null, that is the question
I think you're looking for something like this list here.
-
Re:null or not null, that is the question
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?
-
Re:null or not null, that is the question
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").
-
Re:null or not null, that is the question
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.
-
Re:null or not null, that is the question
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.
-
Re:null or not null, that is the question
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.
-
Re:null or not null, that is the question
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.
-
Re:C, was (Re:Perl and Python)
What about Steve Summit's FAQS?
-
Re:I had the same thing in an interview
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.
-
WRONG BITCH!
I can't think of any language or system offhand in which NULL implies zero. What are you referring to?
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
More about NULL -
Re:In OOXML?
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. -
Re:In OOXML?
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. -
Re:And the Ever Popular...How is it undefined?
I shall quote the C++ standard, because that's what I have.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.
(ISO 14882:2003, clause 5.4)
The above code prescribes two modifications; one from the ++ and one from the assignment.i = v[i++];
// the behavior is unspecified
Here you would also think that the behavior should be specified completely: i++ has to be evaluated before the array index can be taken which has to be loaded before it can be stored in i, but this isn't necessarily the case.
There are sequence points at function entry and exit, which don't apply here, and at the end of each statement.
I'm pretty sure that my reading is right (if you (regular) Google this expression you'll get a number of hits saying it's undefined, including a couple on the C faq (in particular, 3.3), but I'm not exactly an expert, so if you can cite sources that say more than "well, it should be this way because if you think about it..." I'm open to being proved wrong. -
Re:Doesn't seem to be true
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.