On 4/20/13 4:57 AM, Igor Galić wrote:
----- Original Message -----
TS-1820 Introduce TS_UNUSED, and migrate most of the code to use
either C++ style unused parameters, or this new macro
[snip]
Commit: e343dbbc60819256e8db7bc0d1f0ae7a4067c7cf
Parents: 3840df1
[snip]
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/e343dbbc/example/add-header/add-header.c
----------------------------------------------------------------------
diff --git a/example/add-header/add-header.c
b/example/add-header/add-header.c
index c0fd6f4..a329162 100644
--- a/example/add-header/add-header.c
+++ b/example/add-header/add-header.c
@@ -35,13 +35,15 @@
#include <ctype.h>
#include <stdio.h>
#include <string.h>
-#include <ts/ts.h>
+
+#include "ts/ts.h"
+#include "ink_defs.h"
You don't mention this conversion in the comments, what's the motivation behind
it?
it's how we generally do it in the core: "" denotes an include in our source
tree, <> an external dependency. Yes,I know that's not exactly what it
means as far as C is concerned, but I find it a useful standard to adhere to.
The reason why it was <ts/ts.h> before is because, as you know, the plugins
were built out of the source tree (and then <> is the right format).
[snip]
@@ -232,7 +236,7 @@ check_ts_version()
}
void
-TSPluginInit(int argc, const char *argv[])
+TSPluginInit(int argc ATS_UNUSED, const char *argv[] ATS_UNUSED)
{
int i, cc;
TSPluginRegistrationInfo info;
Your commit message says TS_UNUSED, but you use ATS_UNUSED
Yes, typo.
Perhaps we should once and for all document when to use ts_ and when ats_
https://cwiki.apache.org/confluence/display/TS/Coding+Style
+1. We decided upon the syntax quite a while ago, and to reiterate, it is
ts_ | TS | TS_ : Public APIs / structures / defines, used in plugins
ink_ |INK | ats_ | ATS | ATS_ : Internal "core" code, not visible to
plugins
(Ideally we'd s/ink_/ats_/ at some point, it was just deemed too invasive
back then :).
I think we may have faulted in some places in the core recently, and using
the wrong prefixes. We should fix that. One reason why this is important is
because we've had several cases where someone uses the public APIs inside
the core. This mostly works, but is incorrect and inefficient (C++ -> C ->
C++ layers, for no good reason).
Thanks!
-- leif