Milan Jurik wrote:
Joerg,
Joerg Schilling píše v po 03. 05. 2010 v 15:34 +0200:
You may be able to agree with me on better thandards than the ones I currently
use but you will not succeed to let me agree on inferior standards.
Well, I do not consider ANSI C and other requirements sent by James
Carlson as "inferior". Which is the basic of our disagreement probably.
You can consider ON gate "C style" as not ideal but it is based on years
of experience of many contributors.
To be fair on the feedback on the short "s" variable name, this is the
name that the OpenGroup spec (and Linux) seem to use here, and therefore
seems OK.
But as for the rest, I have to agree that Jim Carlson's style comments
seem fair:
- Leaving "#ifndef HAS_STRNLEN" in the code seems a really bad idea,
since it's just a bug waiting to happen if the build system somehow
defined this in future (after all, Solaris would have strnlen()), in
which case the function would go away. Why take this risk?
- All of the "#include <schilly/*>" stuff means you're really asking to
integrate multiple schilly header files for one small function, which
seems to make this a much larger project, adding only costs and no real
benefits:
- If you exclude EXPORT as not useful and only confusing on
Solaris, and HAS_STRNLEN as already covered above, the only thing these
includes seem to be giving you is size_t.
- If the end result of all of your feature tests is the same as
sys/types.h, you could have just included sys/types.h.
- If for some reason now or in the future, your include files break
the build or subtly fail to give the correct size_t definition, then
your non-standard build system represents a new bug someone (not
familiar with these files) will need to track down.
- Even if there aren't bugs or maintenance needed for your
includes, someone may spend time verifying that strange behavior down
the road is not caused by something strange, which is wasted effort.
So it certainly seems valid feedback to say "don't be non-standard in
this way".
You can certainly argue that if you're integrating a large chunk of
external code that will want to track external updates, such as AST or
cdrecord or similar, then you could have a valid case for different
styles. But it's really hard to justify this for a single very small
libc function that stands a good change of no edits from upstream, and
maybe no edits at all once integrated.
Hugh.
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
