versadac
1
versadac - Scalable Recorder Firmware
Main Page
Classes
Files
File List
File Members
core
libjson
JSONOptions.h
1
#ifndef JSON_OPTIONS_H
2
#define JSON_OPTIONS_H
3
10
/*
11
* JSON_LIBRARY must be declared if libjson is compiled as a static or dynamic
12
* library. This exposes a C-style interface, but none of the inner workings of libjson
13
*/
14
#define JSON_LIBRARY
15
16
17
/*
18
* JSON_STRICT removes all of libjson's extensions. Meaning no comments, no special numbers
19
*/
20
//#define JSON_STRICT
21
22
23
/*
24
* JSON_DEBUG is used to perform extra error checking. Because libjson usually
25
* does on the fly parsing, validation is impossible, so this option will allow
26
* you to register an error callback so that you can record what is going wrong
27
* before the library crashes. This option does not protect from these errors,
28
* it simply tells you about them, which is nice for debugging, but not preferable
29
* for release candidates
30
*/
31
//#define JSON_DEBUG
32
33
34
/*
35
* JSON_ISO_STRICT turns off all code that uses non-standard C++. This removes all
36
* references to long long and long double as well as a few others
37
*/
38
//#define JSON_ISO_STRICT
39
40
41
/*
42
* JSON_SAFE performs similarly to JSON_DEBUG, except this option does protect
43
* from the errors that it encounters. This option is recommended for those who
44
* feel it's possible for their program to encounter invalid json.
45
*/
46
#define JSON_SAFE
47
48
49
/*
50
* JSON_STDERROR routes error messages to cerr instead of a callback, this
51
* option hides the callback registering function. This will usually display
52
* messages in the console
53
*/
54
//#define JSON_STDERROR
55
56
57
/*
58
* JSON_PREPARSE causes all parsing to be done immediately. By default, libjson
59
* parses nodes on the fly as they are needed, this makes parsing much faster if
60
* your program gets a lot of information that it doesn't need. An example of
61
* this would be a client application communicating with a server if the server
62
* returns things like last modified date and other things that you don't use.
63
*/
64
//#define JSON_PREPARSE
65
66
67
/*
68
* JSON_LESS_MEMORY will force libjson to let go of memory as quickly as it can
69
* this is recommended for software that has to run on less than optimal machines.
70
* It will cut libjson's memory usage by about 20%, but also run slightly slower.
71
* It's recommended that you also compile using the -Os option, as this will also
72
* reduce the size of the library
73
*/
74
//#define JSON_LESS_MEMORY
75
76
77
/*
78
* JSON_UNICODE tells libjson to use wstrings instead of regular strings, this
79
* means that libjson supports the full array of unicode characters, but also takes
80
* much more memory and processing power.
81
*/
82
#define JSON_UNICODE
83
84
85
/*
86
* JSON_REF_COUNT causes libjson to reference count JSONNodes, which makes copying
87
* and passing them around much faster. It is recommended that this stay on for
88
* most uses
89
*/
90
#define JSON_REF_COUNT
91
92
93
/*
94
* JSON_BINARY is used to support binary, which is base64 encoded and decoded by libjson,
95
* if this option is not turned off, no base64 support is included
96
*/
97
#define JSON_BINARY
98
99
100
/*
101
* JSON_EXPOSE_BASE64 is used to turn on the functionality of libjson's base64 encoding
102
* and decoding. This may be useful if you want to obfuscate your json, or send binary data over
103
* a network
104
*/
105
#define JSON_EXPOSE_BASE64
106
107
108
/*
109
* JSON_ITERATORS turns on all of libjson's iterating functionality. This would usually
110
* only be turned off while compiling for use with C
111
*/
112
//#define JSON_ITERATORS
113
114
115
/*
116
* JSON_STREAM turns on libjson's streaming functionality. This allows you to give parts of
117
* your json into a stream, which will automatically hit a callback when full nodes are
118
* completed
119
*/
120
#define JSON_STREAM
121
122
123
/*
124
* JSON_MEMORY_CALLBACKS exposes functions to register callbacks for allocating, resizing,
125
* and freeing memory. Because libjson is designed for customizability, it is feasible
126
* that some users would like to further add speed by having the library utilize a memory
127
* pool. With this option turned on, the default behavior is still done internally unless
128
* a callback is registered. So you can have this option on and not use it.
129
*/
130
//#define JSON_MEMORY_CALLBACKS
131
132
133
/*
134
* JSON_MEMORY_MANAGE is used to create functionality to automatically track and clean
135
* up memory that has been allocated by the user. This includes strings, binary data, and
136
* nodes. It also exposes bulk delete functions.
137
*/
138
#define JSON_MEMORY_MANAGE
139
140
141
/*
142
* JSON_MEMORY_POOL Turns on libjson's iteraction with mempool++. It is more efficient that simply
143
* connecting mempool++ to the callbacks because it integrates things internally and uses a number
144
* of memory pools. This value tells libjson how large of a memory pool to start out with. 500KB
145
* should suffice for most cases. libjson will distribute that within the pool for the best
146
* performance depending on other settings.
147
*/
148
//#define JSON_MEMORY_POOL 524288
149
150
151
/*
152
* JSON_MUTEX_CALLBACKS exposes functions to register callbacks to lock and unlock
153
* mutexs and functions to lock and unlock JSONNodes and all of it's children. This
154
* does not prevent other threads from accessing the node, but will prevent them from
155
* locking it. It is much easier for the end programmer to allow libjson to manage
156
* your mutexs because of reference counting and manipulating trees, libjson automatically
157
* tracks mutex controls for you, so you only ever lock what you need to
158
*/
159
//#define JSON_MUTEX_CALLBACKS
160
161
162
/*
163
* JSON_MUTEX_MANAGE lets you set mutexes and forget them, libjson will not only keep
164
* track of the mutex, but also keep a count of how many nodes are using it, and delete
165
* it when there are no more references
166
*/
167
//#define JSON_MUTEX_MANAGE
168
169
170
/*
171
* JSON_NO_C_CONSTS removes consts from the C interface. It still acts the same way, but
172
* this may be useful for using the header with languages or variants that don't have const
173
*/
174
//#define JSON_NO_C_CONSTS
175
176
177
/*
178
* JSON_OCTAL allows libjson to use octal values in numbers.
179
*/
180
//#define JSON_OCTAL
181
182
183
/*
184
* JSON_WRITE_PRIORITY turns on libjson's writing capabilties. Without this libjson can only
185
* read and parse json, this allows it to write back out. Changing the value of the writer
186
* changes how libjson compiles, and how fast it will go when writing
187
*/
188
#define JSON_WRITE_PRIORITY HIGH
189
190
191
/*
192
* JSON_READ_PRIORITY turns on libjson's reading capabilties. Changing the value of the reader
193
* changes how libjson compiles, and how fast it will go when writing
194
*/
195
#define JSON_READ_PRIORITY MED
196
197
198
/*
199
* JSON_NEWLINE affects how libjson writes. If this option is turned on, libjson
200
* will use whatever it's defined as for the newline signifier, otherwise, it will use
201
* standard unix \n.
202
*/
203
//#define JSON_NEWLINE "\r\n" //\r\n is standard for most windows and dos programs
204
205
206
/*
207
* JSON_INDENT affects how libjson writes. If this option is turned on, libjson
208
* will use \t to indent formatted json, otherwise it will use the number of characters
209
* that you specify. If this is not turned on, then it will use the tab (\t) character
210
*/
211
//#define JSON_INDENT " "
212
213
214
/*
215
* JSON_ESCAPE_WRITES tells the libjson engine to escape special characters when it writes
216
* out. If this option is turned off, the json it outputs may not adhere to JSON standards
217
*/
218
#define JSON_ESCAPE_WRITES
219
220
221
/*
222
* JSON_COMMENTS tells libjson to store and write comments. libjson always supports
223
* parsing json that has comments in it as it simply ignores them, but with this option
224
* it keeps the comments and allows you to insert further comments
225
*/
226
//#define JSON_COMMENTS
227
228
229
/*
230
* JSON_WRITE_BASH_COMMENTS will cause libjson to write all comments in bash (#) style
231
* if this option is not turned on, then it will use C-style comments. Bash comments are
232
* all single line
233
*/
234
//#define JSON_WRITE_BASH_COMMENTS
235
236
237
/*
238
* JSON_WRITE_SINGLE_LINE_COMMENTS will cause libjson to write all comments in using //
239
* notation, or (#) if that option is on. Some parsers do not support multiline C comments
240
* although, this option is not needed for bash comments, as they are all single line anyway
241
*/
242
//#define JSON_WRITE_SINGLE_LINE_COMMENTS
243
244
245
/*
246
* JSON_ARRAY_SIZE_ON_ON_LINE allows you to put small arrays of primitives all on one line
247
* in a write_formatted. This is common for tuples, like coordinates. If must be defined
248
* as an integer
249
*/
250
//#define JSON_ARRAY_SIZE_ON_ONE_LINE 2
251
252
253
/*
254
* JSON_VALIDATE turns on validation features of libjson.
255
*/
256
#define JSON_VALIDATE
257
258
259
/*
260
* JSON_CASE_INSENSITIVE_FUNCTIONS turns on funtions for finding child nodes in a case-
261
* insenititve way
262
*/
263
#define JSON_CASE_INSENSITIVE_FUNCTIONS
264
265
266
/*
267
* JSON_INDEX_TYPE allows you th change the size type for the children functions. If this
268
* option is not used then unsigned int is used. This option is useful for cutting down
269
* on memory, or using huge numbers of child nodes (over 4 billion)
270
*/
271
//#define JSON_INDEX_TYPE unsigned int
272
273
274
/*
275
* JSON_BOOL_TYPE lets you change the bool type for the C interface. Because before C99 there
276
* was no bool, and even then it's just a typedef, you may want to use something else. If this
277
* is not defined, it will revert to int
278
*/
279
//#define JSON_BOOL_TYPE char
280
281
282
/*
283
* JSON_INT_TYPE lets you change the int type for as_int. If you ommit this option, the default
284
* long will be used
285
*/
286
//#define JSON_INT_TYPE long
287
288
289
/*
290
* JSON_NUMBER_TYPE lets you change the number type for as_float as well as the internal storage for the
291
* number. If you omit this option, the default double will be used for most cases and float for JSON_LESS_MEMORY
292
*/
293
//#define JSON_NUMBER_TYPE double
294
295
296
/*
297
* JSON_STRING_HEADER allows you to change the type of string that libjson uses both for the
298
* interface and internally. It must implement most of the STL string interface, but not all
299
* of it. Things like wxString or QString should wourk without much trouble
300
*/
301
//#define JSON_STRING_HEADER "../TestSuite/StringTest.h"
302
303
304
/*
305
* JSON_UNIT_TEST is used to maintain and debug the libjson. It makes all private
306
* members and functions public so that tests can do checks of the inner workings
307
* of libjson. This should not be turned on by end users.
308
*/
309
//#define JSON_UNIT_TEST
310
311
312
/*
313
* JSON_NO_EXCEPTIONS turns off any exception throwing by the library. It may still use exceptions
314
* internally, but the interface will never throw anything.
315
*/
316
//#define JSON_NO_EXCEPTIONS
317
318
319
/*
320
* JSON_DEPRECATED_FUNCTIONS turns on functions that have been deprecated, this is for backwards
321
* compatibility between major releases. It is highly recommended that you move your functions
322
* over to the new equivalents
323
*/
324
//#define JSON_DEPRECATED_FUNCTIONS
325
326
327
/*
328
* JSON_CASTABLE allows you to call as_bool on a number and have it do the 0 or not 0 check,
329
* it also allows you to ask for a string from a number, or boolean, and have it return the right thing.
330
* Without this option, those types of requests are undefined. It also exposes the as_array, as_node, and cast
331
* functions
332
*/
333
#define JSON_CASTABLE
334
335
336
/*
337
* JSON_SECURITY_MAX_NEST_LEVEL is a security measure added to make prevent against DoS attacks
338
* This only affects validation, as if you are worried about security attacks, then you are
339
* most certainly validating json before sending it to be parsed. This option allows you to limitl how many
340
* levels deep a JSON Node can go. 128 is a good depth to start with
341
*/
342
#define JSON_SECURITY_MAX_NEST_LEVEL 128
343
344
345
/*
346
* JSON_SECURITY_MAX_STRING_LENGTH is another security measure, preventing DoS attacks with very long
347
* strings of JSON. 32MB is the default value for this, this allows large images to be embedded
348
*/
349
#define JSON_SECURITY_MAX_STRING_LENGTH 33554432
350
351
352
/*
353
* JSON_SECURITY_MAX_STREAM_OBJECTS is a security measure for streams. It prevents DoS attacks with
354
* large number of objects hitting the stream all at once. 128 is a lot of objects, but not out of
355
* the question for high speed systems.
356
*/
357
#define JSON_SECURITY_MAX_STREAM_OBJECTS 128
358
359
#endif
360
Generated on Wed Aug 19 2020 10:33:42 for versadac by
1.8.9.1