121–130 of 178 posts
Am I OCD when I cringe when I see 'p_rite' where he (I think) means 'p_write'? That alone would knock a few points off a candidate doing this test when he's interviewing with me. 'rite' can mean 'write' or 'right' or even 'allright' - why the unnecessary confusion?
See also: http://en.wikipedia.org/wiki/Muphrys_Law
Am I OCD when I cringe when I see 'p_rite' where he (I think) means 'p_write'? That alone would knock a few points off a candidate doing this test when he's interviewing with me. 'rite' can mean 'write' or 'right' or even 'allright' - why the unnecessary confusion?
I think he used p_rite so that the variable names length is identical to p_read, which can make the code look more pretty.
Earlier quoted context omitted.
Although I'm not sure "its K&R equivalent" is correct (that's C89 and has "modern" function implementations), C99 is indeed not that common. If only because many compilers don't support it (including Microsoft's).
Bah, I learned my C from K&R 2nd ed. I guess that's not K&R C, is it? :-)
At least, if I recall correctly.
Interesting. I didn't try to do the assignment when I read the first part, but just tried it now before looking at the second part. When I started to write the main loop, I felt uneasy when I realized I'd be doing unnecessary copying in the common case when char_to_remove is never found. My code ended up a tad more complex than yours due to desire to avoid that: void condense_by_removing(char *z_terminated, char char…
Earlier quoted context omitted.
I see what you're trying to do, but it won't work this way. Since your termination condition is z_terminated[index], you must never look beyond index, yet you access [index+write]. This alone means the code's buggy. The second version is similarly flawed. Note that your code instantly becomes much easier to understand if you rename the variable 'write' to 'gap'.
Ehh, good point. :-/ The second version is identical to the first, except that it ises the z_terminated pointer instead of a separate index. void condense_by_removing(char* z_terminated, char char_to_remove) { int gap = 0; for (; *(z_terminated + gap); ++z_terminated) { if (*(z_terminated + gap) == char_to_remove) { ++gap; } if (gap > 0) { *z_terminated = *(z_terminated + gap); } } *z_terminated = 0; } Interestingly…
Earlier quoted context omitted.
'\0' is a character, not a string. The string is "\0". Also, C strings are NUL -terminated, not NULL -terminated. (char)(0) is the NUL character; (void * )(0) is the NULL pointer (usually).
The C standard exclusively uses the phrase "null-terminated" to refer to strings.
Earlier quoted context omitted.
'\0' is a character, not a string. The string is "\0". Also, C strings are NUL -terminated, not NULL -terminated. (char)(0) is the NUL character; (void * )(0) is the NULL pointer (usually).
Actually it's the NULL pointer by definition. 0 is always equivalent to NULL in pointer context, even though you're working with some hypothetical crazy system where NULL is actually #define NULL 1337. It's mandated by the standard. If (NULL == 0) isn't true you're not using C.
void * p;
memset(&p, 0, sizeof(p));
assert(p == NULL);
Sadly, the code YOU wrote is suboptimal. It doesn't check for bad pointers, has no comments, doesn't take memory corruption into consideration, and assumes the replacement character is not '\0'. You would get a C- if I graded your test. Now you'll argue that it's just a test, but the fact is your best work should not come only when under unexpected scrutiny, as it does with impromptu tests, it should be a mental proc…
However, I wonder if you've actually taken on board either the point of the exercise, or the fact that it isn't yet finished.
However, questions such as those you raise are, of course, of great interest in production code, and would be raised in the discussion this code is intended to start. If someone started to write correct code that took these things into consideration the test would be stopped - it would've served its purpose already.
I'd be interested to know:
* Do you think every routine, every piece of code should have comments?
* Do you think every routine should test its input parameters? Every time?
* Do you think every routine should be checking for memory corruption? All the time?
* How do you cope with memory corruption in the program code itself?
* Do you think the routine fails if the char to remove is '\0'? Are you sure? You seem to claim it does.
* Do you believe that all code should always be written to the same standard?
Having written code in an environment where any given memory location has a MTC (Mean Time to Corruption) of 12 hours, I have considered these issues. I'd be interested to hear your experiences in these matters.
I notice also that you created your username specifically to reply to this item.
Welcome to Hacker News.
Sadly, the code YOU wrote is suboptimal. It doesn't check for bad pointers, has no comments, doesn't take memory corruption into consideration, and assumes the replacement character is not '\0'. You would get a C- if I graded your test. Now you'll argue that it's just a test, but the fact is your best work should not come only when under unexpected scrutiny, as it does with impromptu tests, it should be a mental proc…
C is a foot-shooting language. Its basic library functions are expected to do what you tell them to do, even when it's a really bad idea. Checking for bad pointers (and how exactly you define "bad" is a rather interesting question) is clearly out of scope.
has no comments
True, but I'm not convinced there's much point on such a trivial piece of code.
doesn't take memory corruption into consideration
Given that there is no redundant information available, this is an impossible challenge.
and assumes the replacement character is not '\0'.
Try re-reading the code a bit more closely.