Code:#include <stdio.h> #include <stdlib.h> int main(void) { char (*j)[1] = NULL; j = (char (*)[1]) malloc( 10000000 ); (*j)[0] = 'a'; printf("%c", (*j)[10000000]); return 0; }
no output, no warnings, why? what is going on "deep inside"?
Code:#include <stdio.h> #include <stdlib.h> int main(void) { char (*j)[1] = NULL; j = (char (*)[1]) malloc( 10000000 ); (*j)[0] = 'a'; printf("%c", (*j)[10000000]); return 0; }
no output, no warnings, why? what is going on "deep inside"?
Before I explain anything, I would like to know: where did you come across this program and why do you need it explained? Is this just trivia?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Aka is this school work!^^^ also I reccommend mallock(sizeof())
Expert C programming deep secrets,
just interesting why not output in this case
Well let's see
- it's an out of bound memory access
- the output stream isn't flushed
Or perhaps it's because that bit of memory contains zero.Code:$ valgrind ./a.out ==4069== Memcheck, a memory error detector ==4069== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==4069== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info ==4069== Command: ./a.out ==4069== ==4069== Invalid read of size 1 ==4069== at 0x40056D: main (in /home/sc/Documents/a.out) ==4069== Address 0x5b5b6c0 is 0 bytes after a block of size 10,000,000 alloc'd ==4069== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==4069== by 0x40055D: main (in /home/sc/Documents/a.out) ==4069== ==4069== ==4069== HEAP SUMMARY: ==4069== in use at exit: 10,000,000 bytes in 1 blocks ==4069== total heap usage: 1 allocs, 0 frees, 10,000,000 bytes allocated ==4069== ==4069== LEAK SUMMARY: ==4069== definitely lost: 0 bytes in 0 blocks ==4069== indirectly lost: 0 bytes in 0 blocks ==4069== possibly lost: 10,000,000 bytes in 1 blocks ==4069== still reachable: 0 bytes in 0 blocks ==4069== suppressed: 0 bytes in 0 blocks ==4069== Rerun with --leak-check=full to see details of leaked memory ==4069== ==4069== For counts of detected and suppressed errors, rerun with: -v ==4069== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
The nul character doesn't have any visual representation, so you might apparently see "nothing".Code:$ ./a.out | odx 000000 00 >.< 000001
> Expert C programming deep secrets,
I really hope they're not trying to tell you something useful here.
The only message should be "This is broken - don't do it!"
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Right. One way to find out is to change the %c format specifier to %u then cast the expression to unsigned int and observe what is printed. My guess is that you observed the printing of a null character.
That said, I note that the code results in undefined behaviour: j is a pointer to an array of 1 char. It is allocated memory for 10000000 arrays of 1 char. Then j is dereferenced and the element at index 10000000 of the array that it points to is accessed. The problem is, this element does not exist, not even if we consider the memory allocated for the subsequent 9999999 arrays of 1 char.
Oh, and then there is no free to match the malloc.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I'm not familiar with that particular book/article/whatever. However, there is a phenomenon that a lot of material that claims to expose "deep secrets" of C actually encourages code with undefined behaviour, and therefore encourages bad programming technique. This is apparently one of those cases, as per laserlight's description.
If I was king of C for a day, I'd burn all such books and delete all electronic forms of such documentation.
What page is it from?
I had a quick look through mine and couldn't find it.
Fact - Beethoven wrote his first symphony in C
What page number is this on? I'd like to check my copy (which is really a good book; I can't recall any "undefined behavior" encouraged in it).
I just played a little with example from
Syntax Only a Compiler Could Love
char (*j)[20]; /* j is a pointer to an array of 20 char */
j = (char (*)[20]) malloc( 20 );
also I made a cast to unsigned int as Laserlight suggested and could see 0 in output.
I found this book great - I'd burn a lot of other books before this one
Edit - snip - question answered
Grumpy - this is as entertaining as a coding books get. Try it, you'll love it, it will change your life! I couldn't recommend it more.
Last edited by Click_here; 10-14-2012 at 05:43 AM.
Fact - Beethoven wrote his first symphony in C
O_ono output, no warnings, why? what is going on "deep inside"?
I don't think anyone has answered most of this question so I'll answer the rest for you.
You don't get any warnings for two reasons: C doesn't care about array boundaries by default; you've told the compiler you know what you are doing with the cast.
Essentially, you don't get any warnings because you've told the compiler not to give you any warnings.
We actually have no way of knowing. (The author of the book has no way of knowing.)what is going on "deep inside"?
In the real world compilers usually treat real "pointers to arrays" differently than "pointers to pointers which just happen to point to an array" in the same way they treat real arrays, arrays on the stack say, differently than pointers to arrays. The usual approach for real "pointers to arrays" is to treat them as being a simple pointer to the first element of the array. (In other words, the value of the pointer is the address of the first element of the array in the same way that the array name decays into a pointer that points to the first element of the array.) That mechanism is invisible to the programmer and can't cause problems because you can't change where an array points with confirming code (Obviously, you can with exploits, but I'm ignoring that insanity.) in any event. That isn't the only possibility; as long as the result is the same the underlying mechanism is invisible.
In other words, what happens "deep inside" is entirely the domain of the compiler vendor; however, it doesn't matter what happens "deep inside" so that information isn't useful.
What's up with people wanting entertainment from education books?this is as entertaining as a coding books get.
I'd guess that grumpy already knows more than the author so I'm no sure how much would actually change.Try it, you'll love it, it will change your life! I couldn't recommend it more.
Soma
So that the author (Peter van der Linden) of the quite excellent book "Expert C Programming: Deep C Secrets" is not further maligned I must state that the OP's code is only loosely based on something from the text.
The text is not for learning how to program in C, but is instead written by a compiler developer (from Sun) and is about the oddities of the language from that perspective.
I wouldn't call it "entertaining" so much as "interesting". And although it is next to retarded for click to suggest that it would change grumpy's life, he probably would learn something from it and find it a good read.
The cost of software maintenance increases with the square of the programmer's creativity. - Robert D. Bliss
It was just a joking sales pitch, don't take it seriouslyAnd although it is next to retarded for click to suggest that it would change grumpy's life
I wouldn't expect someone like grumpy to learn a lot from this book (programming wise) - But it has lots of fun stories thoughout is - Such as the bug that brought down AT&T phone system and two different bugs that bought down two different space probes - It has a funny story about Bill Gates. It's not a large book and I still recommend it.
PVDL did it because (to quote the book) -"Few authors conveyed the idea that anyone might enjoy programming" and "Programming is a marvellous, vital, challenging activity, and books on programming should brim over with enthusiasm for it!"What's up with people wanting entertainment from education books?
The section that the OP has played around with is based on a section on how to read declarations in C, not on what is happening inside the compiler. As the OP stated, the text had nothing to do with code given.
Fact - Beethoven wrote his first symphony in C
I see. That makes sense.
I agree that it's a great book. But definitely not a beginner's book.
The cost of software maintenance increases with the square of the programmer's creativity. - Robert D. Bliss
