On 22 May 2002 11:40, Petr Vandrovec wrote:
> Function name is not documentation. Documentation documents function
> API, or, in case documentation is not available, source does it.
> copy_to_user_dude_I_return_uncopied_length_on_error_not_EFAULT_parameters_
>are_same_as_for_memcpy() is unacceptable name, and anything shorter does not
> document things you must know.
Anything can be taken to the ridiculous extreme: "let's use ci() and co()!
We will document 'em and everything will be fine!"
Let's abstain from this type of discussion.
> I'm not sure that I want to use kernel which contains code written
> by people who do not read API documentation. I expect that everyone
> here tests every branch in code he writes at least once - and such test
> would (f.e.) quickly reveal that read(fd, NULL, 1000) does not return -1 &
> set errno to EFAULT, but instead returns complete success (1000) on
> affected sound drivers.
In the ideal world. We're in the real world and there *is* broken code,
as demonstrated by Rusty. If we can reduce chances of programming errors by
choosing good names, we have to do it.
Which name is 'good'/too short/too long is up to "big boys" to decide.
I presume they know better, I don't hack on kernel day and night. They do.
-- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 23 2002 - 22:00:25 EST