Earlier quoted context omitted.
That's what I intended when I used it (with an extra 'volatile'). My objective was to test the crash reporter tool.
Came here to say this!
:: or -> this?
*(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
181–190 of 199 posts
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#182Earlier quoted context omitted.
That's not just a beautiful high-level description, it's even therapeutic: the next time my HDD is thrashing I'll sit patiently and think that the Page King is too busy ruling his kingdom to grant my humble request right now.
Or being held hostage
For example, by my forgetting that the "-j" option of "make" had the number of concurrent tasks as an optional parameter, and without that it simply launches every possible compile simultaneously. Paralysis of course: given its uncanny tendency to pick the wrong target I could just about believe that the OOM killer then sniped the King
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#183To me this talk was rather confusing. This statement cannot occur in a well formed standard C or C++ program, and I don’t think that the speaker did a good job conveying this. They also took way too much time to get to the actual point. If the intention was to discuss the particularities of memory mapping on some popular systems, they should have used bitcast from the start.
> This statement cannot occur in a well formed standard C or C++ program
Not true. It's illegal to execute that statement because of undefined behavior. But it's legal to have: if (false) { *(char*)0 = 0; }
(And of course it's legal to #ifdef it out or comment it out, but that's too much cheating.)
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#184Earlier quoted context omitted.
You're mostly correct but to be pedantic, in C the literal value 0 does not actually mean address 0. The literal value of 0 is an implementation defined value that represents a null pointer, but that value does not have to be address 0, it could be some other address. This is significant because the following two snippets of code are not required to be equal in C. char* c = (char*)(0); char* d; memset(&d, 0, sizeof(d…
How do you reference literal address 0, then? From how you describe it sounds different from literal address 1, etc.
somewhat covered in different hacker news post, for C, roughly:
[]
*()++
So really, address one is literally address 0 + epsilon, where epsilon is minimal addressable bit group, typically 8 bit clean without seg fault.
Although, for standard x86, epsilon size would depend on which ring/boot method level & asm addressing method available (8,16,32,64).
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#185Earlier quoted context omitted.
yes, compiler will align integers on word boundaries. casting to char, just uses the first 8 bits of integer word. Char was originaly just sematic macro for integer. pointer to char is 8 sequenial bits somewhere in the group of integer spaced bits. if you're lucky, the 8 bits are at the start of the integer group of bits, otherwise, segfault. Originaly using anonymous unions & placing largest bit count variable as fi…
I see you've been lucky enough to only work on systems where CHAR_BIT=8. It's not an alignment issue because there may not be a distinct pointer representation for the other bits, rather than alignment issues where a pointer representation exists even if you can't use it.
ummm... sounds like a unsigned char same as signed char reference. Lot of fun debugging 32 bit int (big, little and mixed endian) over char absolution position always starts at left and is contiguous.
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#186Earlier quoted context omitted.
Adding to the above, in the 1980s and 1990s it was not uncommon to interface and write code for chips that were 12 bit and 24 bit based (instrumentation accumulators for example, "cheapest sufficient" chips for particular jobs, etc). Today you can still work with (say) TI DSP chips that spit complex FFT pipelines results once per cycle and have absolutely no 8-bit hardware addressing or masking abilities as they're l…
Out of curiosity, how do you deal with I/O on such systems? ISO C simultaneously requires that blocks of memory roundtrip through binary I/O (so it can’t truncate chars to octets) and that fgetc() and friends return unsigned chars cast to an ints or EOF (so you really want the range of int to include the range of unsigned char, even if you could technically depend on the implementation-defined overflow behaviour). Th…
Stick to delimited ascii & send over tcp/ip, perhaps use asn/bers specs. -- UTF / json / xml nice unification of everything, as long as don't forget sending UTF flag.
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#187Not a big fan of the format of the talk. The guy is a good orator, but it takes ages to go to the point. A bit annoying if you're actually interested in the technical part rather than the jokes.
You sound like fun at parties :p I’m glad you liked the oration and technical content though!
no *fun() deref-ing?
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#188To me this talk was rather confusing. This statement cannot occur in a well formed standard C or C++ program, and I don’t think that the speaker did a good job conveying this. They also took way too much time to get to the actual point. If the intention was to discuss the particularities of memory mapping on some popular systems, they should have used bitcast from the start.
> This statement cannot occur in a well formed standard C or C++ program Not true. It's illegal to execute that statement because of undefined behavior. But it's legal to have: if (false) { *(char*)0 = 0; } (And of course it's legal to #ifdef it out or comment it out, but that's too much cheating.)
Umm... lot of undefined behavior things in official C spec.
Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]
#189To me this talk was rather confusing. This statement cannot occur in a well formed standard C or C++ program, and I don’t think that the speaker did a good job conveying this. They also took way too much time to get to the actual point. If the intention was to discuss the particularities of memory mapping on some popular systems, they should have used bitcast from the start.
> they should have used bitcast from the start. There are hundreds of instances of (char )0=0; in github, and there are none of the bit_cast variant, so if your goal is to inform people how to read code, starting with the one humans might actually encounter in the wild makes sense.
Most assembler instructions are bit manipulations. just use gcc -S to cast the source code to bits.