It's also worth pointing out that buffers passed to strcpy, memcpy, etc. must not overlap. Otherwise it results in undefined behavior .
memmove() has proper memory moving semantics, and can deal with overlapping buffers.
Some dark corners of C
101–110 of 175 posts
Re: Some dark corners of C
#102Earlier quoted context omitted.
To get it right you have to be able to pick it apart according to specified rules. Being able to work with formally specified rules is an integral part in the study of computer science (also, other STEM majors). I'd say it's a perfectly valid question, as long as someone points out that one should stay away as far as possible from this sort of code.
The question assumes that you KNOW the rule, which is highly unlikely unless you've either been bitten by it or have read through the spec enough times to catch it. Unless you know the actual parsing rules, there's no way to know if a real parser would be greedy or not (or perhaps it might try to be clever?). This is nothing more than a trivia question, which does not test aptitude or intelligence.
It does test knowledge. Nothing wrong with knowledge.
I expect they asked some other questions too.
Re: Some dark corners of C
#103I wrote a compiler for a subset of C, and I'm happily aware of all of these 'dark corners'. That's why I would always recommend writing a compiler for a language if you _really_ want to understand the language.
Re: Some dark corners of C
#104Earlier quoted context omitted.
The compiler can't know at compile time with a naked pointer like it can with an array. [static 1] is handy to say it must not explicitly be NULL, as if it were optional, however.
Yes, but I expected some kind of "You're passing a pointer as an array of size n. I can't check the size, but you should make sure you've checked it".
I can't imagine that would be anything but noise. 99% of my function calls have pointers passed through, not arrays.
Re: Some dark corners of C
#105Ah this just made my day! :)
Re: Some dark corners of C
#106I am almost certain the pointer aliasing thing could be fixed by providing the proper optimization tag at compile time. I remember back in introductory systems classes, we saw mind boggling optimizations from GCC at O3 - the pointer example is so trivial it must be optimized by the compiler!
Re: Some dark corners of C
#107I am almost certain the pointer aliasing thing could be fixed by providing the proper optimization tag at compile time. I remember back in introductory systems classes, we saw mind boggling optimizations from GCC at O3 - the pointer example is so trivial it must be optimized by the compiler!
You can only optimise if you know that it globally isn't ever passed the same, which won't be the case at compile time, as a separate object may be linked which does provide x==z.
Re: Some dark corners of C
#108int x = 'FOO!'; will not make demons fly out of your nose: it is not undefined behaviour . It is guaranteed to produce a value; the specific value is implementation defined (that is, one that the compiler vendor has decided and documented), but it is an integer value, not a demon value. I'm sure, though, that someone sooner or later will be bitten by code like int x = 'é'; which is equally implementation-defined.
On big-endian machines, the order of characters is preserved. Because of that, I've noticed this trick used in old network/protocol code where the intent was to use integer values in binary headers while maintaining easy readability if you are look at hex/ascii side-by-side. e.g., int x = 'RIFF'; .. if you were packing a WAVE file header.
It was pretty common in classic Mac OS and PalmOS for writing OStype constants. I vaguely remember that for some time gcc did different things with this construct depending on whether target OS was MacOS/PalmOS or anything else.
Re: Some dark corners of C
#109For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…
"heap" goes back at least to Algol 68, where you could write (using case stropping)
REF INT i = HEAP INT; # sort of like C++ "new" # REF INT i = LOC INT; # allocates from the stack #
or the shorter forms
HEAP INT i; LOC INT i;
Re: Some dark corners of C
#110I don't get it. What will happen if you violate the language semantics? They call it 'dark corners'? If you hit your head against a wall, it will hurt. Is it a 'dark corner' of life? Overall, the presentation is very weak, like from a yesterday's graduate.
I am glad we all aren't experts like you then, some of the stuff I knew from before, some were really relieving.
So I am glad it was posted, it helped, me, and this comment page was also, something to both smile/laugh and learn something from. Thanks