This file is indexed.

/usr/include/libee/libee.h is in libee-dev 0.4.1-1.1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
/**
 * @mainpage
 * Libee - An Event Expression Library inspired by CEE
 *
 * Copyright 2010-2011 by Rainer Gerhards and Adiscon GmbH.
 *
 * CEE is an upcoming standard used to describe network events
 * in a number of normalized formats. It's goal is to unify they currently
 * many different representations that exist in the industry.
 *
 * The core idea of libee is to provide a small but hopefully convenient
 * API layer above the CEE standard. However, CEE is not finished. At the
 * time of this writing, CEE is under heavy development and even some of
 * its core data structures (like the data dictionary and taxonmy) have
 * not been fully specified.
 *
 * So, as libee developer, I obviously have an issue here: I can't craft
 * something in code that does not really exist at this very moment. My
 * solution to this problem is to let me inspire by CEE discussions and
 * then code what makes most sense in the light of that. I will try hard
 * to keep up with the draft standard, but some deviation is probably
 * unavoidable. This is one primary reasons that gave libee it's name:
 * we were tempted to name it libcee, as this is what the idea of it is,
 * but we can not yet do so because we don't know how, and how fast, CEE
 * will evolve. The compromise is to use a name that suggests libee and
 * CEE may be different things. It is my sincere hope that libee will
 * be a full CEE implementation when the standard is finally released, but
 * for obvious reasons I cannot guarantee that.
 *
 * So for the time being, libee should be thought of as a useful library
 * that helps you get your events normalized. If you program cleanly to
 * libee, chances are not bad that only relatively little effort is required
 * to move your app over to be CEE compliant (once the standard is out).
 *
 * Performance is definitely
 * a goal of this library. As such, it tries to generate in-memory
 * representations of expression objects that will be fast to work with.
 * Multi-threaded applications and plugin architectures are fully
 * supported. For the time being, this means that multiple threads
 * are safe as long as different library contexts are being used. It
 * is \b not safe to use the same context concurrently. In the future,
 * ctx may support in-context concurreny via specific options, but
 * this is outside the scope of the initial effort.
 *
 * The libee homepage is available at http://www.libee.org/
 *
 * More information on CEE can be found: http://cee.mitre.org/
 *
 * @section dataStructures Data Structures
 * @subsection ctx The Library Context
 *
 * All functions in this library depend on the so-called library context.
 * It provides support for using multiple independent instances of libee
 * inside a single program, e.g. in plugin-based systems. The library context
 * stores things that usually go into global variables, things like
 * a global debug handler, compliance levels, tuning paramters and so
 * on. A typical, non-plugin based program should never need more than
 * a single library context. Think of it as an additional abstraction
 * layer to facilitate working with multiple independend instances of libee
 * at the same time within the same program.
 *
 * The context must be provided upon each object creation. Once an object
 * has been created, it remains bound to the context used during creation.
 * <b>No object can be shared between multiple contextes</b>. During creation,
 * the context is stored within each object. All successive calls use this
 * in-object context. This is especially important as some libxml2 functions,
 * on which we heavily rely, do not permit to pass more than one object pointer.
 * As such, this object must contain the required context object, as we need
 * it for proper operation.
 *
 * For obvious reasons, a libray context must only be destructed after \b all
 * objects that use it have been destructed as well. The context itsefl
 * <b>does not</b> keep track of which other objects use it (this is a
 * decision based on performance reasons).
 *
 * @subsection setBucket On Sets and Buckets
 *
 * The CEE standard uses the term "set" to organize/group related tags and
 * fields. So this term is not available for any other use. However, we need
 * to have a container that can hold one or many of these objects. We have
 * named these containers "buckets". So we have tag and field buckets, each
 * of which contain a number of tags or fields.
 *
 * The idea behind this is that we may sometimes need to group all of an
 * event's tags and fields together. One reason may be that e.g. the tag
 * bucket can be created before the actual event. One other may be that 
 * a tag bucketmay even be used without an event record already be created
 * (e.g. as a performance optimization, where the tag bucket is created
 * on a global level and then re-used to populate each actual event instance
 * -- something that is NOT YET IMPLEMENTED!).
 *
 * Introduction of the bucket classes provide an easy way to handle this
 * situation.
 *
 * @section appendix Appendix
 * @subsection ceeCompliance CEE Compliance
 * While I try to keep compatible with CEE for obvious reasons, the standard
 * is not yet finished. Many details are not even decided. For this reason,
 * libee will evolve in parallel and not necessarily be aligned to the
 * latest CEE spec.
 *
 * @subsection apiStability API Stability
 * 
 * At the time of this writing, CEE is a moving target. While I try
 * to keep things consistent, I do NOT yet guarantee stability of the
 * ctx API. Do not expect a stable version before ctx version 1.x.x
 * is announced. As I used ctx in my own projects, I obviously will
 * do my best to break as few things as possible. But depending on
 * CEE movements, some things may break. You have been warned ;)
 * 
 * On the name "ctx": while ctx aims to be a full implementation
 * of the CEE standard, I could not guarantee this at the time I
 * initiated this project. At this time, the CEE standard was far from
 * being completed and frequent changes were anticipated.
 * I was under a number of resource constraints and so could not commit
 * to keep the library in line with CEE no matter where CEE would head
 * to. While it was tempting to call the library "libcee", and many
 * suggested so, I used a similar, but different name to reduce potential
 * friction out of different needs of the CEE standards body and my
 * development project. If things go well, ctx may evolve into
 * something that becomes the "official" libcee.
 *
 * Libee fully supports Unicode. Like most Linux tools, it operates
 * on UTF-8 natively, called "passive mode". This was decided because we
 * so can keep the size of data structures small while still supporting
 * all of the world's languages (actually more than when we did UCS-2).
 * This is the same concept used by libxml2, on which ctx heavily 
 * relies for all XML-based functionality.
 *
 *//*
 *
 * ctx - a CEE-based event expression library
 * Copyright 2010 by Rainer Gerhards and Adiscon GmbH.
 *
 * This file is part of ctx.
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
 *
 * A copy of the LGPL v2.1 can be found in the file "COPYING" in this distribution.
 */
#ifndef LIBEE_H_INCLUDED
#define	LIBEE_H_INCLUDED
#include <stdlib.h>	/* we need size_t */
#include <libestr.h>
#include "libee/obj.h"
#include "libee/ctx.h"
#include "libee/timestamp.h"
#include "libee/value.h"
#include "libee/fieldtype.h"
#include "libee/field.h"
#include "libee/fieldbucket.h"
#include "libee/primitivetype.h"
#include "libee/tagbucket.h"
#include "libee/event.h"

/* some private error codes (always negative)
 */
#define EE_OK 0
#define EE_ERR -1
#define EE_NOMEM -2
#define EE_EOF -3
#define EE_INVLDFMT -4
#define EE_FIELDHASNAME -5
#define EE_TOOMANYVALUES -6
#define EE_WRONGPARSER -7
#define EE_EINVAL -8 		/* invalid value provided on API */
#define EE_NOTFOUND -9 		/* some object could not be found */

/* some important constants */
#define LIBEE_CEE_MAX_VALS_PER_FIELD 255
	/**< CEE-defined maximum number of values per field. The
	 * current value reflects CEE CLS 0.5.1
	 */
#endif /* #ifndef EE_H_INCLUDED */