vlm | 9ca1504 | 2004-08-07 06:03:15 +0000 | [diff] [blame] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| 2 | |
| 3 | <!--Converted with LaTeX2HTML 2002-2-1 (1.70) |
| 4 | original version by: Nikos Drakos, CBLU, University of Leeds |
| 5 | * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan |
| 6 | * with significant contributions from: |
| 7 | Jens Lippmann, Marek Rouchal, Martin Wilck and others --> |
| 8 | <HTML> |
| 9 | <HEAD> |
| 10 | <TITLE>Using the Free ASN.1 Compiler</TITLE> |
| 11 | <META NAME="description" CONTENT="Using the Free ASN.1 Compiler"> |
| 12 | <META NAME="asn1c, ASN.1, free, compiler, BER, DER, PER, XER\"> |
| 13 | |
| 14 | <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> |
| 15 | <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> |
| 16 | |
| 17 | |
| 18 | </HEAD> |
| 19 | |
| 20 | <BODY > |
| 21 | |
| 22 | <P> |
| 23 | |
| 24 | <P> |
| 25 | |
| 26 | <P> |
| 27 | <H1 ALIGN="CENTER">Using the Free ASN.1 Compiler</H1><DIV> |
| 28 | |
| 29 | <P ALIGN="CENTER"><STRONG>Lev Walkin <vlm@lionet.info></STRONG></P> |
| 30 | </DIV> |
| 31 | <BR> |
| 32 | |
| 33 | <H2><A NAME="SECTION01000000000000000000"> |
| 34 | Contents</A> |
| 35 | </H2> |
| 36 | <!--Table of Contents--> |
| 37 | |
| 38 | <UL> |
| 39 | <LI><A NAME="tex2html38" |
| 40 | HREF="asn1c-usage.html#SECTION02000000000000000000">ASN.1 Basics</A> |
| 41 | <UL> |
| 42 | <LI><A NAME="tex2html39" |
| 43 | HREF="asn1c-usage.html#SECTION02100000000000000000">Abstract Syntax Notation: ASN.1</A> |
| 44 | <UL> |
| 45 | <LI><A NAME="tex2html40" |
| 46 | HREF="asn1c-usage.html#SECTION02110000000000000000">Some of the ASN.1 Basic Types</A> |
| 47 | <UL> |
| 48 | <LI><A NAME="tex2html41" |
| 49 | HREF="asn1c-usage.html#SECTION02111000000000000000">The BOOLEAN type</A> |
| 50 | <LI><A NAME="tex2html42" |
| 51 | HREF="asn1c-usage.html#SECTION02112000000000000000">The INTEGER type</A> |
| 52 | <LI><A NAME="tex2html43" |
| 53 | HREF="asn1c-usage.html#SECTION02113000000000000000">The ENUMERATED type</A> |
| 54 | <LI><A NAME="tex2html44" |
| 55 | HREF="asn1c-usage.html#SECTION02114000000000000000">The OCTET STRING type</A> |
| 56 | <LI><A NAME="tex2html45" |
| 57 | HREF="asn1c-usage.html#SECTION02115000000000000000">The OBJECT IDENTIFIER type</A> |
| 58 | <LI><A NAME="tex2html46" |
| 59 | HREF="asn1c-usage.html#SECTION02116000000000000000">The RELATIVE-OID type</A> |
| 60 | </UL> |
| 61 | <LI><A NAME="tex2html47" |
| 62 | HREF="asn1c-usage.html#SECTION02120000000000000000">Some of the ASN.1 String Types</A> |
| 63 | <UL> |
| 64 | <LI><A NAME="tex2html48" |
| 65 | HREF="asn1c-usage.html#SECTION02121000000000000000">The IA5String type</A> |
| 66 | <LI><A NAME="tex2html49" |
| 67 | HREF="asn1c-usage.html#SECTION02122000000000000000">The UTF8String type</A> |
| 68 | <LI><A NAME="tex2html50" |
| 69 | HREF="asn1c-usage.html#SECTION02123000000000000000">The NumericString type</A> |
| 70 | <LI><A NAME="tex2html51" |
| 71 | HREF="asn1c-usage.html#SECTION02124000000000000000">The PrintableString type</A> |
| 72 | <LI><A NAME="tex2html52" |
| 73 | HREF="asn1c-usage.html#SECTION02125000000000000000">The VisibleString type</A> |
| 74 | </UL> |
| 75 | <LI><A NAME="tex2html53" |
| 76 | HREF="asn1c-usage.html#SECTION02130000000000000000">ASN.1 Constructed Types</A> |
| 77 | <UL> |
| 78 | <LI><A NAME="tex2html54" |
| 79 | HREF="asn1c-usage.html#SECTION02131000000000000000">The SEQUENCE type</A> |
| 80 | <LI><A NAME="tex2html55" |
| 81 | HREF="asn1c-usage.html#SECTION02132000000000000000">The SET type</A> |
| 82 | <LI><A NAME="tex2html56" |
| 83 | HREF="asn1c-usage.html#SECTION02133000000000000000">The CHOICE type</A> |
| 84 | <LI><A NAME="tex2html57" |
| 85 | HREF="asn1c-usage.html#SECTION02134000000000000000">The SEQUENCE OF type</A> |
| 86 | <LI><A NAME="tex2html58" |
| 87 | HREF="asn1c-usage.html#SECTION02135000000000000000">The SET OF type</A> |
| 88 | </UL> |
| 89 | </UL> |
| 90 | </UL><BR> |
| 91 | <LI><A NAME="tex2html59" |
| 92 | HREF="asn1c-usage.html#SECTION03000000000000000000">Using the ASN.1 Compiler</A> |
| 93 | <UL> |
| 94 | <LI><A NAME="tex2html60" |
| 95 | HREF="asn1c-usage.html#SECTION03100000000000000000">Introduction to the ASN.1 Compiler</A> |
| 96 | <UL> |
| 97 | <LI><A NAME="tex2html61" |
| 98 | HREF="asn1c-usage.html#SECTION03110000000000000000">Quick start</A> |
| 99 | <LI><A NAME="tex2html62" |
| 100 | HREF="asn1c-usage.html#SECTION03120000000000000000">Slow start</A> |
| 101 | <UL> |
| 102 | <LI><A NAME="tex2html63" |
| 103 | HREF="asn1c-usage.html#SECTION03121000000000000000">Recognizing compiler output</A> |
| 104 | <LI><A NAME="tex2html64" |
| 105 | HREF="asn1c-usage.html#SECTION03122000000000000000">Invoking the ASN.1 helper code from the application</A> |
| 106 | </UL> |
| 107 | </UL> |
| 108 | </UL><BR> |
| 109 | <LI><A NAME="tex2html65" |
| 110 | HREF="asn1c-usage.html#SECTION04000000000000000000">Bibliography</A> |
| 111 | </UL> |
| 112 | <!--End of Table of Contents--> |
| 113 | |
| 114 | <P> |
| 115 | |
| 116 | <H1><A NAME="SECTION02000000000000000000"> |
| 117 | ASN.1 Basics</A> |
| 118 | </H1> |
| 119 | |
| 120 | <P> |
| 121 | |
| 122 | <H1><A NAME="SECTION02100000000000000000"> |
| 123 | Abstract Syntax Notation: ASN.1</A> |
| 124 | </H1> |
| 125 | |
| 126 | <P> |
| 127 | <I>This chapter defines some basic ASN.1 concepts and describes |
| 128 | several most widely used types. It is by no means an authoritative |
| 129 | or complete reference. For more complete ASN.1 description, please |
| 130 | refer to Olivier Dubuisson's book [<A |
| 131 | HREF="asn1c-usage.html#Dub00">Dub00</A>] or the ASN.1 body |
| 132 | of standards itself [<A |
| 133 | HREF="asn1c-usage.html#ITU-T_ASN.1">ITU-T/ASN.1</A>].</I> |
| 134 | |
| 135 | <P> |
| 136 | The Abstract Syntax Notation One is used to formally describe the |
| 137 | semantics of data transmitted across the network. Two communicating |
| 138 | parties may have different formats of their native data types (i.e. |
| 139 | number of bits in the integer type), thus it is important to have |
| 140 | a way to describe the data in a manner which is independent from the |
| 141 | particular machine's representation. The ASN.1 specifications is used |
| 142 | to achieve one or more of the following: |
| 143 | |
| 144 | <P> |
| 145 | |
| 146 | <UL> |
| 147 | <LI>The specification expressed in the ASN.1 notation is a formal and |
| 148 | precise way to communicate the data semantics to human readers; |
| 149 | </LI> |
| 150 | <LI>The ASN.1 specifications may be used as input for automatic compilers |
| 151 | which produce the code for some target language (C, C++, Java, etc) |
| 152 | to encode and decode the data according to some encoding rules (which |
| 153 | are also defined by the ASN.1 standard). |
| 154 | </LI> |
| 155 | </UL> |
| 156 | Consider the following example: |
| 157 | |
| 158 | <P> |
| 159 | |
| 160 | <DD><PRE> |
| 161 | |
| 162 | Rectangle ::= SEQUENCE { |
| 163 | height INTEGER, |
| 164 | width INTEGER |
| 165 | } |
| 166 | |
| 167 | </PRE> |
| 168 | </DD> |
| 169 | This ASN.1 specification describes a constructed type, <I>Rectangle</I>, |
| 170 | containing two integer fields. This specification may tell the reader |
| 171 | that there is this kind of data structure and that some entity may |
| 172 | be prepared to send or receive it. The question on <I>how</I> that |
| 173 | entity is going to send or receive the <I>encoded data</I> is outside |
| 174 | the scope of ASN.1. For example, this data structure may be encoded |
| 175 | according to some encoding rules and sent to the destination using |
| 176 | the TCP protocol. The ASN.1 specifies several ways of encoding (or |
| 177 | ''serializing'', or ''marshaling'') the data: BER, CER, DER and |
| 178 | XER, some of them which will be described later. |
| 179 | |
| 180 | <P> |
| 181 | The complete specification must be wrapped in a module, which looks |
| 182 | like this: |
| 183 | |
| 184 | <P> |
| 185 | |
| 186 | <DD><PRE> |
| 187 | |
| 188 | UsageExampleModule1 |
| 189 | { iso org(3) dod(6) internet(1) private(4) |
| 190 | enterprise(1) spelio(9363) software(1) |
| 191 | asn1c(5) docs(2) usage(1) 1 } |
| 192 | AUTOMATIC TAGS DEFINITIONS ::= |
| 193 | BEGIN |
| 194 | |
| 195 | -- This is a comment which describes nothing. |
| 196 | Rectangle ::= SEQUENCE { |
| 197 | height INTEGER, -- Height of the rectangle |
| 198 | width INTEGER, -- Width of the rectangle |
| 199 | } |
| 200 | |
| 201 | END |
| 202 | |
| 203 | </PRE> |
| 204 | </DD> |
| 205 | The module header consists of module name (UsageExampleModule1), the |
| 206 | module object identifier ({...}), some flags (AUTOMATIC TAGS) and |
| 207 | ''DEFINITIONS ::= BEGIN''. The module ends with an ''END'' statement. |
| 208 | |
| 209 | <P> |
| 210 | |
| 211 | <H1><A NAME="SECTION02110000000000000000"> |
| 212 | Some of the ASN.1 Basic Types</A> |
| 213 | </H1> |
| 214 | |
| 215 | <P> |
| 216 | |
| 217 | <H2><A NAME="SECTION02111000000000000000"> |
| 218 | The BOOLEAN type</A> |
| 219 | </H2> |
| 220 | |
| 221 | <P> |
| 222 | The BOOLEAN type models the simple binary TRUE/FALSE, YES/NO, ON/OFF |
| 223 | or a similar kind of two-way choice. |
| 224 | |
| 225 | <P> |
| 226 | |
| 227 | <H2><A NAME="SECTION02112000000000000000"> |
| 228 | The INTEGER type</A> |
| 229 | </H2> |
| 230 | |
| 231 | <P> |
| 232 | The INTEGER type is a signed natural number type without any restrictions |
| 233 | on its size. If the automatic checking on INTEGER value bounds are |
| 234 | necessary, the subtype constraints must be used. |
| 235 | |
| 236 | <P> |
| 237 | |
| 238 | <DD><PRE> |
| 239 | |
| 240 | SimpleInteger ::= INTEGER |
| 241 | -- An integer with a very limited range |
| 242 | SmallInt ::= INTEGER (0..127) |
| 243 | -- Integer, negative |
| 244 | NegativeInt ::= INTEGER (MIN..0) |
| 245 | |
| 246 | </PRE> |
| 247 | </DD> |
| 248 | |
| 249 | <P> |
| 250 | |
| 251 | <H2><A NAME="SECTION02113000000000000000"> |
| 252 | The ENUMERATED type</A> |
| 253 | </H2> |
| 254 | |
| 255 | <P> |
| 256 | The ENUMERATED type is semantically equivalent to the INTEGER type |
| 257 | with some integer values explicitly named. |
| 258 | |
| 259 | <P> |
| 260 | |
| 261 | <DD><PRE> |
| 262 | |
| 263 | FruitId ::= ENUMERATED { apple(1), orange(2) } |
| 264 | -- The numbers in braces are optional, |
| 265 | -- the enumeration may be performed |
| 266 | -- automatically by the compiler |
| 267 | ComputerOSType ::= ENUMERATED { |
| 268 | FreeBSD, -- will be 0 |
| 269 | Windows, -- will be 1 |
| 270 | Solaris(5), -- will remain 5 |
| 271 | Linux, -- will be 6 |
| 272 | MacOS -- will be 7 |
| 273 | } |
| 274 | |
| 275 | </PRE> |
| 276 | </DD> |
| 277 | |
| 278 | <P> |
| 279 | |
| 280 | <H2><A NAME="SECTION02114000000000000000"> |
| 281 | The OCTET STRING type</A> |
| 282 | </H2> |
| 283 | |
| 284 | <P> |
| 285 | This type models the sequence of 8-bit bytes. This may be used to |
| 286 | transmit some opaque data or data serialized by other types of encoders |
| 287 | (i.e. video file, photo picture, etc). |
| 288 | |
| 289 | <P> |
| 290 | |
| 291 | <H2><A NAME="SECTION02115000000000000000"> |
| 292 | The OBJECT IDENTIFIER type</A> |
| 293 | </H2> |
| 294 | |
| 295 | <P> |
| 296 | The OBJECT IDENTIFIER is used to represent the unique identifier of |
| 297 | any object, starting from the very root of the registration tree. |
| 298 | If your organization needs to uniquely identify something (a router, |
| 299 | a room, a person, a standard, or whatever), you are encouraged to |
| 300 | get your own identification subtree at http://www.iana.org/protocols/forms.htm. |
| 301 | |
| 302 | <P> |
| 303 | For example, the very first ASN.1 module in this document has the |
| 304 | following OBJECT IDENTIFIER: 1 3 6 1 4 1 9363 1 5 2 1 1. |
| 305 | |
| 306 | <P> |
| 307 | |
| 308 | <DD><PRE> |
| 309 | |
| 310 | ExampleOID ::= OBJECT IDENTIFIER |
| 311 | usageExampleModule1-oid ExampleOID |
| 312 | ::= { 1 3 6 1 4 1 9363 1 5 2 1 1 } |
| 313 | -- An identifier of the Internet. |
| 314 | internet-id OBJECT IDENTIFIER |
| 315 | ::= { iso(1) identified-organization(3) |
| 316 | dod(6) internet(1) } |
| 317 | |
| 318 | </PRE> |
| 319 | </DD> |
| 320 | As you see, names are optional. |
| 321 | |
| 322 | <P> |
| 323 | |
| 324 | <H2><A NAME="SECTION02116000000000000000"> |
| 325 | The RELATIVE-OID type</A> |
| 326 | </H2> |
| 327 | |
| 328 | <P> |
| 329 | The RELATIVE-OID type has the semantics of a subtree of an OBJECT |
| 330 | IDENTIFIER. There may be no need to repeat the whole sequence of numbers |
| 331 | from the root of the registration tree where the only thing of interest |
| 332 | is some of the tree's subsequence. |
| 333 | |
| 334 | <P> |
| 335 | |
| 336 | <DD><PRE> |
| 337 | |
| 338 | this-document RELATIVE-OID ::= { docs(2) usage(1) } |
| 339 | this-example RELATIVE-OID ::= { |
| 340 | this-document assorted-examples(0) this-example(1) } |
| 341 | |
| 342 | </PRE> |
| 343 | </DD> |
| 344 | |
| 345 | <P> |
| 346 | |
| 347 | <H1><A NAME="SECTION02120000000000000000"> |
| 348 | Some of the ASN.1 String Types</A> |
| 349 | </H1> |
| 350 | |
| 351 | <P> |
| 352 | |
| 353 | <H2><A NAME="SECTION02121000000000000000"> |
| 354 | The IA5String type</A> |
| 355 | </H2> |
| 356 | |
| 357 | <P> |
| 358 | This is essentially the ASCII, with 128 character codes available |
| 359 | (7 lower bits of 8-bit byte). |
| 360 | |
| 361 | <P> |
| 362 | |
| 363 | <H2><A NAME="SECTION02122000000000000000"> |
| 364 | The UTF8String type</A> |
| 365 | </H2> |
| 366 | |
| 367 | <P> |
| 368 | This is the character string which encodes the full Unicode range |
| 369 | (4 bytes) using multibyte character sequences. |
| 370 | |
| 371 | <P> |
| 372 | |
| 373 | <H2><A NAME="SECTION02123000000000000000"> |
| 374 | The NumericString type</A> |
| 375 | </H2> |
| 376 | |
| 377 | <P> |
| 378 | This type represents the character string with the alphabet consisting |
| 379 | of numbers (''0'' to ''9'') and a space. |
| 380 | |
| 381 | <P> |
| 382 | |
| 383 | <H2><A NAME="SECTION02124000000000000000"> |
| 384 | The PrintableString type</A> |
| 385 | </H2> |
| 386 | |
| 387 | <P> |
| 388 | The character string with the following alphabet: space, ''<B>'</B>'' |
| 389 | (single quote), ''<B>(</B>'', ''<B>)</B>'', ''<B>+</B>'', |
| 390 | '','' (comma), ''<B>-</B>'', ''<B>.</B>'', ''<B>/</B>'', |
| 391 | digits (''0'' to ''9''), ''<B>:</B>'', ''<B>=</B>'', ''<B>?</B>'', |
| 392 | upper-case and lower-case letters (''A'' to ''Z'' and ''a'' |
| 393 | to ''z'') |
| 394 | |
| 395 | <P> |
| 396 | |
| 397 | <H2><A NAME="SECTION02125000000000000000"> |
| 398 | The VisibleString type</A> |
| 399 | </H2> |
| 400 | |
| 401 | <P> |
| 402 | The character string with the alphabet which is more or less a subset |
| 403 | of ASCII between space and ''~'' (tilde). Alternatively, |
| 404 | the alphabet may be represented as the PrintableString alphabet described |
| 405 | earlier, plus the following characters: ''<B>!</B>'', ''<B>''</B>'', |
| 406 | ''<B>#</B>'', ''<B>$</B>'', ''<B>%</B>'', ''<B>&</B>'', |
| 407 | ''<B>*</B>'', ''<B>;</B>'', ''<B><</B>'', ''<B>></B>'', |
| 408 | ''<B>[</B>'', ''<B>\</B>'', ''<B>]</B>'', |
| 409 | ''<B>^</B>'', ''<B>_</B>'', ''<B>`</B>'' |
| 410 | (single left quote), ''<B>{</B>'', ''<B>|</B>'', ''<B>}</B>'', |
| 411 | ''~''. |
| 412 | |
| 413 | <P> |
| 414 | |
| 415 | <H1><A NAME="SECTION02130000000000000000"> |
| 416 | ASN.1 Constructed Types</A> |
| 417 | </H1> |
| 418 | |
| 419 | <P> |
| 420 | |
| 421 | <H2><A NAME="SECTION02131000000000000000"> |
| 422 | The SEQUENCE type</A> |
| 423 | </H2> |
| 424 | |
| 425 | <P> |
| 426 | This is an ordered collection of other simple or constructed types. |
| 427 | The SEQUENCE constructed type resembles the C ''struct'' statement. |
| 428 | |
| 429 | <P> |
| 430 | |
| 431 | <DD><PRE> |
| 432 | |
| 433 | Address ::= SEQUENCE { |
| 434 | -- The apartment number may be omitted |
| 435 | apartmentNumber NumericString OPTIONAL, |
| 436 | streetName PrintableString, |
| 437 | cityName PrintableString, |
| 438 | stateName PrintableString, |
| 439 | -- This one may be omitted too |
| 440 | zipNo NumericString OPTIONAL |
| 441 | } |
| 442 | |
| 443 | </PRE> |
| 444 | </DD> |
| 445 | |
| 446 | <P> |
| 447 | |
| 448 | <H2><A NAME="SECTION02132000000000000000"> |
| 449 | The SET type</A> |
| 450 | </H2> |
| 451 | |
| 452 | <P> |
| 453 | This is a collection of other simple or constructed types. Ordering |
| 454 | is not important. The data may arrive in the order which is different |
| 455 | from the order of specification. Data is encoded in the order not |
| 456 | necessarily corresponding to the order of specification. |
| 457 | |
| 458 | <P> |
| 459 | |
| 460 | <H2><A NAME="SECTION02133000000000000000"> |
| 461 | The CHOICE type</A> |
| 462 | </H2> |
| 463 | |
| 464 | <P> |
| 465 | This type is just a choice between the subtypes specified in it. The |
| 466 | CHOICE type contains at most one of the subtypes specified, and it |
| 467 | is always implicitly known which choice is being decoded or encoded. |
| 468 | This one resembles the C ''union'' statement. |
| 469 | |
| 470 | <P> |
| 471 | The following type defines a response code, which may be either an |
| 472 | integer code or a boolean ''true''/''false'' code. |
| 473 | |
| 474 | <P> |
| 475 | |
| 476 | <DD><PRE> |
| 477 | |
| 478 | ResponseCode ::= CHOICE { |
| 479 | intCode INTEGER, |
| 480 | boolCode BOOLEAN |
| 481 | } |
| 482 | |
| 483 | </PRE> |
| 484 | </DD> |
| 485 | |
| 486 | <P> |
| 487 | |
| 488 | <H2><A NAME="SECTION02134000000000000000"> |
| 489 | The SEQUENCE OF type</A> |
| 490 | </H2> |
| 491 | |
| 492 | <P> |
| 493 | This one is the list (array) of simple or constructed types: |
| 494 | |
| 495 | <P> |
| 496 | |
| 497 | <DD><PRE> |
| 498 | |
| 499 | -- Example 1 |
| 500 | ManyIntegers ::= SEQUENCE OF INTEGER |
| 501 | -- Example 2 |
| 502 | ManyRectangles ::= SEQUENCE OF Rectangle |
| 503 | -- More complex example: |
| 504 | -- an array of structures defined in place. |
| 505 | ManyCircles ::= SEQUENCE OF SEQUENCE { |
| 506 | radius INTEGER |
| 507 | } |
| 508 | |
| 509 | </PRE> |
| 510 | </DD> |
| 511 | |
| 512 | <P> |
| 513 | |
| 514 | <H2><A NAME="SECTION02135000000000000000"> |
| 515 | The SET OF type</A> |
| 516 | </H2> |
| 517 | |
| 518 | <P> |
| 519 | The SET OF type models the bag of structures. It resembles the SEQUENCE |
| 520 | OF type, but the order is not important: i.e. the elements may arrive |
| 521 | in the order which is not necessarily the same as the in-memory order |
| 522 | on the remote machines. |
| 523 | |
| 524 | <P> |
| 525 | |
| 526 | <DD><PRE> |
| 527 | |
| 528 | -- A set of structures defined elsewhere |
| 529 | SetOfApples :: SET OF Apple |
| 530 | -- Set of integers encoding the kind of a fruit |
| 531 | FruitBag ::= SET OF ENUMERATED { apple, orange } |
| 532 | |
| 533 | </PRE> |
| 534 | </DD> |
| 535 | |
| 536 | <P> |
| 537 | |
| 538 | <H1><A NAME="SECTION03000000000000000000"> |
| 539 | Using the ASN.1 Compiler</A> |
| 540 | </H1> |
| 541 | |
| 542 | <P> |
| 543 | |
| 544 | <H1><A NAME="SECTION03100000000000000000"> |
| 545 | Introduction to the ASN.1 Compiler</A> |
| 546 | </H1> |
| 547 | |
| 548 | <P> |
| 549 | The purpose of the ASN.1 compiler, of which this document is part, |
| 550 | is to convert the ASN.1 specifications to some other target language |
| 551 | (currently, only C is supported<A NAME="tex2html1" |
| 552 | HREF="#foot136"><SUP>2.1</SUP></A>). The compiler reads the specification and emits a series of target |
| 553 | language structures and surrounding maintenance code. For example, |
| 554 | the C structure which may be created by compiler to represent the |
| 555 | simple <I>Rectangle</I> specification defined earlier in this document, |
| 556 | may look like this<A NAME="tex2html2" |
| 557 | HREF="#foot315"><SUP>2.2</SUP></A>: |
| 558 | |
| 559 | <P> |
| 560 | |
| 561 | <DD><PRE> |
| 562 | |
| 563 | typedef struct Rectangle_s { |
| 564 | int height; |
| 565 | int width; |
| 566 | } Rectangle_t; |
| 567 | |
| 568 | </PRE> |
| 569 | </DD> |
| 570 | This would not be of much value for such a simple specification, so |
| 571 | the compiler goes further and actually produces the code which fills |
| 572 | in this structure by parsing the binary<A NAME="tex2html3" |
| 573 | HREF="#foot142"><SUP>2.3</SUP></A> data provided in some buffer. It also produces the code that takes |
| 574 | this structure as an argument and performs structure serialization |
| 575 | by emitting a series of bytes. |
| 576 | |
| 577 | <P> |
| 578 | |
| 579 | <H1><A NAME="SECTION03110000000000000000"> |
| 580 | Quick start</A> |
| 581 | </H1> |
| 582 | |
| 583 | <P> |
| 584 | After building and installing the compiler, the asn1c command may |
| 585 | be used to compile the ASN.1 specification<A NAME="tex2html4" |
| 586 | HREF="#foot316"><SUP>2.4</SUP></A>: |
| 587 | |
| 588 | <P> |
| 589 | |
| 590 | <DD><PRE> |
| 591 | |
| 592 | asn1c <I><spec.asn1></I> |
| 593 | |
| 594 | </PRE> |
| 595 | </DD> |
| 596 | If several specifications contain interdependencies, all of them must |
| 597 | be specified: |
| 598 | |
| 599 | <P> |
| 600 | |
| 601 | <DD><PRE> |
| 602 | |
| 603 | asn1c <I><spec1.asn1> <spec2.asn1> ...</I> |
| 604 | |
| 605 | </PRE> |
| 606 | </DD> |
| 607 | The compiler -E and -EF options are used for testing the parser and |
| 608 | the semantic fixer, respectively. These options will instruct the |
| 609 | compiler to dump out the parsed (and fixed) ASN.1 specification as |
| 610 | it was "understood" by the compiler. It might might |
| 611 | be useful to check whether a particular syntactic construction is |
| 612 | properly supported by the compiler. |
| 613 | |
| 614 | <P> |
| 615 | |
| 616 | <DD><PRE> |
| 617 | |
| 618 | asn1c -EF <I><spec-to-test.asn1></I> |
| 619 | |
| 620 | </PRE> |
| 621 | </DD> |
| 622 | The -P option is used to dump the compiled output on the screen instead |
| 623 | of creating a bunch of .c and .h files on disk in the current directory. |
| 624 | You would probably want to start with -P option instead of creating |
| 625 | a mess in your current directory. |
| 626 | |
| 627 | <P> |
| 628 | |
| 629 | <H1><A NAME="SECTION03120000000000000000"> |
| 630 | Slow start</A> |
| 631 | </H1> |
| 632 | |
| 633 | <P> |
| 634 | |
| 635 | <H2><A NAME="SECTION03121000000000000000"> |
| 636 | Recognizing compiler output</A> |
| 637 | </H2> |
| 638 | |
| 639 | <P> |
| 640 | After compiling, the following entities will be created in your current |
| 641 | directory: |
| 642 | |
| 643 | <P> |
| 644 | |
| 645 | <UL> |
| 646 | <LI>A set of .c and .h files, generally a single pair for each type defined |
| 647 | in the ASN.1 specifications. These files will be named similarly to |
| 648 | the ASN.1 types (<I>Rectangle.c</I> and <I>Rectangle.h</I> for the |
| 649 | specification defined in the beginning of this document). |
| 650 | </LI> |
| 651 | <LI>A set of helper .c and .h files which contain generic encoders, decoders |
| 652 | and other useful routines. There will be many of them, some of them |
| 653 | even not necessary<A NAME="tex2html5" |
| 654 | HREF="#foot161"><SUP>2.5</SUP></A>, but the overall amount of code after compiling will be rather small |
| 655 | anyway. |
| 656 | </LI> |
| 657 | </UL> |
| 658 | It is your responsibility to create .c file with the <I>int main()</I> |
| 659 | routine and the Makefile (if needed). Compiler helps you with the |
| 660 | latter by creating the Makefile.am.sample, containing the skeleton |
| 661 | definition for the automake, should you want to use autotools. |
| 662 | |
| 663 | <P> |
| 664 | In other words, after compiling the Rectangle module, you have the |
| 665 | following set of files: { Makefile.am.sample, Rectangle.c, Rectangle.h, |
| 666 | <B>...</B> }, where <B>''...''</B> stands for the |
| 667 | set of additional ''helper'' files created by the compiler. If you |
| 668 | add the simple file with the <I>int main()</I> routine, it would even |
| 669 | be possible to compile everything with the single instruction: |
| 670 | |
| 671 | <P> |
| 672 | |
| 673 | <DD><PRE> |
| 674 | |
| 675 | cc -o rectangle *.c # It could be <I>that</I> simple<A NAME="tex2html6" |
| 676 | HREF="#foot319"><SUP>2.6</SUP></A> |
| 677 | |
| 678 | </PRE> |
| 679 | </DD> |
| 680 | |
| 681 | <P> |
| 682 | |
| 683 | <H2><A NAME="SECTION03122000000000000000"> |
| 684 | Invoking the ASN.1 helper code from the application</A> |
| 685 | </H2> |
| 686 | |
| 687 | <P> |
| 688 | First of all, you would want to include one or more header files into |
| 689 | your application. For the Rectangle module, including the Rectangle.h |
| 690 | file is enough: |
| 691 | |
| 692 | <P> |
| 693 | |
| 694 | <DD><PRE> |
| 695 | |
| 696 | #include <Rectangle.h> |
| 697 | |
| 698 | </PRE> |
| 699 | </DD> |
| 700 | The header files defines the C structure corresponding to the ASN.1 |
| 701 | definition of a rectangle and the declaration of the ASN.1 type descriptor, |
| 702 | which is used as an argument to most of the functions provided by |
| 703 | the ASN.1 module. For example, here is the code which frees the Rectangle_t |
| 704 | structure: |
| 705 | |
| 706 | <P> |
| 707 | |
| 708 | <DD><PRE> |
| 709 | |
| 710 | Rectangle_t *rect = ; |
| 711 | asn1_DEF_Rectangle->free_struct(&asn1_DEF_Rectangle, |
| 712 | rect, 0); |
| 713 | |
| 714 | </PRE> |
| 715 | </DD> |
| 716 | This code defines a <I>rect</I> pointer which points to the Rectangle_t |
| 717 | structure which needs to be freed. The second line invokes the generic |
| 718 | free_struct routine created specifically for this Rectangle_t structure. |
| 719 | The <I>asn1_DEF_Rectangle</I> is the type descriptor, which holds |
| 720 | a collection of generic routines to deal with the Rectangle_t structure. |
| 721 | |
| 722 | <P> |
| 723 | There are several generic functions available: |
| 724 | |
| 725 | <P> |
| 726 | <DL> |
| 727 | <DT><STRONG>check_constraints</STRONG></DT> |
| 728 | <DD>Check that the contents of the target structure |
| 729 | are semantically valid and constrained to appropriate implicit or |
| 730 | explicit subtype constraints. Please refer to Section sub:Validating-the-target. |
| 731 | </DD> |
| 732 | <DT><STRONG>ber_decoder</STRONG></DT> |
| 733 | <DD>This is the generic <I>restartable</I><A NAME="tex2html7" |
| 734 | HREF="#foot183"><SUP>2.7</SUP></A> BER decoder (Basic Encoding Rules). This decoder would create |
| 735 | and/or fill the target structure for you. Please refer to Section |
| 736 | [<A HREF="#sub:Decoding-BER">Decoding-BER</A>]. |
| 737 | </DD> |
| 738 | <DT><STRONG>der_encoder</STRONG></DT> |
| 739 | <DD>This is the generic DER encoder (Distinguished Encoding |
| 740 | Rules). This decoder will take the target structure and encode it |
| 741 | into a series of bytes. Please refer to Section [<A HREF="#sub:Encoding-DER">Encoding-DER</A>]. |
| 742 | </DD> |
| 743 | <DT><STRONG>print_struct</STRONG></DT> |
| 744 | <DD>This function convert the contents of the passed target |
| 745 | structure into human readable form. This form is not formal and cannot |
| 746 | be converted back into the structure, but it may turn out to be useful |
| 747 | for debugging or quick-n-dirty printing. Please refer to Section [<A HREF="#sub:Printing-the-target">Printing-the-target</A>]. |
| 748 | </DD> |
| 749 | <DT><STRONG>free_struct</STRONG></DT> |
| 750 | <DD>This is a generic disposal which frees the target structure. |
| 751 | Please refer to Section [<A HREF="#sub:Freeing-the-target">Freeing-the-target</A>]. |
| 752 | </DD> |
| 753 | </DL> |
| 754 | Each of the above function takes the type descriptor (<I>asn1_DEF_...</I>) |
| 755 | and the target structure (<I>rect</I>, in the above example). The |
| 756 | target structure is typically created by the generic BER decoder or |
| 757 | by the application itself. |
| 758 | |
| 759 | <P> |
| 760 | Here is how the buffer can be deserialized into the structure: |
| 761 | |
| 762 | <P> |
| 763 | |
| 764 | <DD><PRE> |
| 765 | |
| 766 | Rectangle_t * |
| 767 | simple_deserializer(void *buffer, size_t buf_size) { |
| 768 | Rectangle_t *rect = 0; /* Note this 0! */ |
| 769 | ber_dec_rval_t rval; |
| 770 | |
| 771 | rval = asn1_DEF_Rectangle->ber_decoder( |
| 772 | &asn1_DEF_Rectangle, |
| 773 | (void **)&rect, |
| 774 | buffer, buf_size, |
| 775 | 0); |
| 776 | |
| 777 | if(rval<B>.code</B> == RC_OK) { |
| 778 | return rect; /* Decoding succeeded */ |
| 779 | } else { |
| 780 | asn1_DEF_Rectangle->free_struct( |
| 781 | &asn1_DEF_Rectangle, rect, 0); |
| 782 | return 0; |
| 783 | } |
| 784 | } |
| 785 | |
| 786 | </PRE> |
| 787 | </DD> |
| 788 | The code above defines a function, <I>simple_deserializer</I>, which |
| 789 | takes a buffer and its length and expected to return a pointer to |
| 790 | the Rectangle_t structure. Inside, it tries to convert the bytes |
| 791 | passed into the target structure (rect) using the generic BER decoder |
| 792 | and returns the rect pointer afterwards. If the structure cannot be |
| 793 | deserialized, it frees the memory which might be left allocated by |
| 794 | the unfinished <I>ber_decoder</I> routine and returns NULL. <B>This |
| 795 | freeing is necessary</B> because the ber_decoder is a restartable procedure, |
| 796 | and may fail just because there is more data needs to be provided |
| 797 | before decoding could be finalized. The code above obviously does |
| 798 | not take into account the way the <I>ber_decoder</I> failed, so the |
| 799 | freeing is necessary because the part of the buffer may already be |
| 800 | decoded into the structure by the time something goes wrong. |
| 801 | |
| 802 | <P> |
| 803 | Restartable decoding is a little bit trickier: you need to provide |
| 804 | the old target structure pointer (which might be already half-decoded) |
| 805 | and react on RC_WMORE return code. This will be explained later in |
| 806 | Section sub:Decoding-BER |
| 807 | |
| 808 | <P> |
| 809 | |
| 810 | <H3><A NAME="SECTION03122100000000000000"></A><A NAME="sub:Decoding-BER"></A><BR> |
| 811 | Decoding BER |
| 812 | </H3> |
| 813 | |
| 814 | <P> |
| 815 | The Basic Encoding Rules describe the basic way how the structure |
| 816 | can be encoded and decoded. Several other encoding rules (CER, DER) |
| 817 | define a more restrictive versions of BER, so the generic BER parser |
| 818 | is also capable of decoding the data encoded by CER and DER encoders. |
| 819 | The opposite is not true. |
| 820 | |
| 821 | <P> |
| 822 | The ASN.1 compiler provides the generic BER decoder which is implicitly |
| 823 | capable of decoding BER, CER and DER encoded data. |
| 824 | |
| 825 | <P> |
| 826 | The decoder is restartable (stream-oriented), which means that in |
| 827 | case the buffer has less data than it is expected, the decoder will |
| 828 | process whatever it is available and ask for more data to be provided. |
| 829 | Please note that the decoder may actually process less data than it |
| 830 | is given in the buffer, which means that you should be able to make |
| 831 | the next buffer contain the unprocessed part of the previous buffer. |
| 832 | |
| 833 | <P> |
| 834 | Suppose, you have two buffers of encoded data: 100 bytes and 200 bytes. |
| 835 | |
| 836 | <P> |
| 837 | |
| 838 | <UL> |
| 839 | <LI>You may concatenate these buffers and feed the BER decoder with 300 |
| 840 | bytes of data, or |
| 841 | </LI> |
| 842 | <LI>You may feed it the first buffer of 100 bytes of data, realize that |
| 843 | the ber_decoder consumed only 95 bytes from it and later feed the |
| 844 | decoder with 205 bytes buffer which consists of 5 unprocessed bytes |
| 845 | from the first buffer and the latter 200 bytes from the second buffer. |
| 846 | </LI> |
| 847 | </UL> |
| 848 | This is not as convenient as it could be (like, the BER encoder would |
| 849 | consume the whole 100 bytes and keep these 5 bytes in some temporary |
| 850 | storage), but in case of stream-based processing it might actually |
| 851 | be OK. Suggestions are welcome. |
| 852 | |
| 853 | <P> |
| 854 | There are two ways to invoke a BER decoder. The first one is a direct |
| 855 | reference of the type-specific decoder. This way was shown in the |
| 856 | previous example of <I>simple_deserializer</I> function. The second |
| 857 | way is to invoke a <I>ber_decode</I> function, which is just a simple |
| 858 | wrapper of the former approach into a less wordy notation: |
| 859 | |
| 860 | <P> |
| 861 | |
| 862 | <DD><PRE> |
| 863 | |
| 864 | rval = ber_decode(&asn1_DEF_Rectangle, (void **)&rect, |
| 865 | buffer, buf_size); |
| 866 | |
| 867 | </PRE> |
| 868 | </DD> |
| 869 | Note that the initial (asn1_DEF_Rectangle->ber_decoder) reference |
| 870 | is gone, and also the last argument (0) is no longer necessary. |
| 871 | |
| 872 | <P> |
| 873 | These two ways of invocations are fully equivalent. |
| 874 | |
| 875 | <P> |
| 876 | The BER de<I>coder</I> may fail because (<I>the following RC_... |
| 877 | codes are defined in ber_decoder.h</I>): |
| 878 | |
| 879 | <P> |
| 880 | |
| 881 | <UL> |
| 882 | <LI>RC_WMORE: There is more data expected than it is provided (stream |
| 883 | mode continuation feature); |
| 884 | </LI> |
| 885 | <LI>RC_FAIL: General failure to decode the buffer; |
| 886 | </LI> |
| 887 | <LI>... other codes may be defined as well. |
| 888 | </LI> |
| 889 | </UL> |
| 890 | Together with the return code (.code) the ber_dec_rval_t type contains |
| 891 | the number of bytes which is consumed from the buffer. In the previous |
| 892 | hypothetical example of two buffers (of 100 and 200 bytes), the first |
| 893 | call to ber_decode() would return with .code = RC_WMORE and .consumed |
| 894 | = 95. The .consumed field of the BER decoder return value is <B>always</B> |
| 895 | valid, even if the decoder succeeds or fails with any other return |
| 896 | code. |
| 897 | |
| 898 | <P> |
| 899 | Please look into ber_decoder.h for the precise definition of ber_decode() |
| 900 | and related types. |
| 901 | |
| 902 | <P> |
| 903 | |
| 904 | <H3><A NAME="SECTION03122200000000000000"></A><A NAME="sub:Encoding-DER"></A><BR> |
| 905 | Encoding DER |
| 906 | </H3> |
| 907 | |
| 908 | <P> |
| 909 | The Distinguished Encoding Rules is the variant of BER encoding rules |
| 910 | which is oriented on representing the structures with length known |
| 911 | beforehand. This is probably exactly how you want to encode: either |
| 912 | after a BER decoding or after a manual fill-up, the target structure |
| 913 | contains the data which size is implicitly known before encoding. |
| 914 | The DER encoding is used, for example, to encode X.509 certificates. |
| 915 | |
| 916 | <P> |
| 917 | As with BER decoder, the DER encoder may be invoked either directly |
| 918 | from the ASN.1 type descriptor (asn1_DEF_Rectangle) or from the |
| 919 | stand-alone function, which is somewhat simpler: |
| 920 | |
| 921 | <P> |
| 922 | |
| 923 | <DD><PRE> |
| 924 | |
| 925 | /* |
| 926 | * This is a custom function which writes the |
| 927 | * encoded output into some FILE stream. |
| 928 | */ |
| 929 | int _write_stream(void *buffer, size_t size, void *app_key) { |
| 930 | FILE *ostream = app_key; |
| 931 | size_t wrote; |
| 932 | |
| 933 | wrote = fwrite(buffer, 1, size, ostream); |
| 934 | |
| 935 | return (wrote == size) ? 0 : -1; |
| 936 | } |
| 937 | |
| 938 | /* |
| 939 | * This is the serializer itself, |
| 940 | * it supplies the DER encoder with the |
| 941 | * pointer to the custom output function. |
| 942 | */ |
| 943 | ssize_t |
| 944 | simple_serializer(FILE *ostream, Rectangle_t *rect) { |
| 945 | der_enc_rval_t rval; /* Return value */ |
| 946 | |
| 947 | rval = der_encode(&asn1_DEF_Rect, rect, |
| 948 | _write_stream, ostream); |
| 949 | if(rval<B>.encoded</B> == -1) { |
| 950 | /* |
| 951 | * Failure to encode the rectangle data. |
| 952 | */ |
| 953 | fprintf(stderr, ''Cannot encode %s: %s\n'', |
| 954 | rval<B>.failed_type</B>->name, |
| 955 | strerror(errno)); |
| 956 | return -1; |
| 957 | } else { |
| 958 | /* Return the number of bytes */ |
| 959 | return rval.encoded; |
| 960 | } |
| 961 | } |
| 962 | |
| 963 | </PRE> |
| 964 | </DD> |
| 965 | As you see, the DER encoder does not write into some sort of buffer |
| 966 | or something. It just invokes the custom function (possible, multiple |
| 967 | times) which would save the data into appropriate storage. The optional |
| 968 | argument <I>app_key</I> is opaque for the DER encoder code and just |
| 969 | used by <I>_write_stream()</I> as the pointer to the appropriate |
| 970 | output stream to be used. |
| 971 | |
| 972 | <P> |
| 973 | If the custom write function is not given (passed as 0), then the |
| 974 | DER encoder will essentially do the same thing (i.e., encode the data) |
| 975 | but no callbacks will be invoked (so the data goes nowhere). It may |
| 976 | prove useful to determine the size of the structure's encoding before |
| 977 | actually doing the encoding<A NAME="tex2html8" |
| 978 | HREF="#foot253"><SUP>2.8</SUP></A>. |
| 979 | |
| 980 | <P> |
| 981 | Please look into der_encoder.h for the precise definition of der_encode() |
| 982 | and related types. |
| 983 | |
| 984 | <P> |
| 985 | |
| 986 | <H3><A NAME="SECTION03122300000000000000"></A><A NAME="sub:Validating-the-target"></A><BR> |
| 987 | Validating the target structure |
| 988 | </H3> |
| 989 | |
| 990 | <P> |
| 991 | Sometimes the target structure needs to be validated. For example, |
| 992 | if the structure was created by the application (as opposed to being |
| 993 | decoded from some external source), some important information required |
| 994 | by the ASN.1 specification might be missing. On the other hand, the |
| 995 | successful decoding of the data from some external source does not |
| 996 | necessarily mean that the data is fully valid either. It might well |
| 997 | be the case that the specification describes some subtype constraints |
| 998 | that were not taken into account during decoding, and it would actually |
| 999 | be useful to perform the last check when the data is ready to be encoded |
| 1000 | or when the data has just been decoded to ensure its validity according |
| 1001 | to some stricter rules. |
| 1002 | |
| 1003 | <P> |
| 1004 | The asn_check_constraints() function checks the type for various |
| 1005 | implicit and explicit constraints. It is recommended to use asn_check_constraints() |
| 1006 | function after each decoding and before each encoding. |
| 1007 | |
| 1008 | <P> |
| 1009 | Please look into constraints.h for the precise definition of asn_check_constraints() |
| 1010 | and related types. |
| 1011 | |
| 1012 | <P> |
| 1013 | |
| 1014 | <H3><A NAME="SECTION03122400000000000000"></A><A NAME="sub:Printing-the-target"></A><BR> |
| 1015 | Printing the target structure |
| 1016 | </H3> |
| 1017 | |
| 1018 | <P> |
| 1019 | There are two ways to print the target structure: either invoke the |
| 1020 | print_struct member of the ASN.1 type descriptor, or using the asn_fprint() |
| 1021 | function, which is a simpler wrapper of the former: |
| 1022 | |
| 1023 | <P> |
| 1024 | |
| 1025 | <DD><PRE> |
| 1026 | |
| 1027 | asn_fprint(stdout, &asn1_DEF_Rectangle, rect); |
| 1028 | |
| 1029 | </PRE> |
| 1030 | </DD> |
| 1031 | Please look into constr_TYPE.h for the precise definition of asn_fprint() |
| 1032 | and related types. |
| 1033 | |
| 1034 | <P> |
| 1035 | |
| 1036 | <H3><A NAME="SECTION03122500000000000000"></A><A NAME="sub:Freeing-the-target"></A><BR> |
| 1037 | Freeing the target structure |
| 1038 | </H3> |
| 1039 | |
| 1040 | <P> |
| 1041 | Freeing the structure is slightly more complex than it may seem to. |
| 1042 | When the ASN.1 structure is freed, all the members of the structure |
| 1043 | and their submembers etc etc are recursively freed too. But it might |
| 1044 | not be feasible to free the structure itself. Consider the following |
| 1045 | case: |
| 1046 | |
| 1047 | <P> |
| 1048 | |
| 1049 | <DD><PRE> |
| 1050 | |
| 1051 | struct my_figure { /* The custom structure */ |
| 1052 | int flags; /* <some custom member> */ |
| 1053 | /* The type is generated by the ASN.1 compiler */ |
| 1054 | <I>Rectangle_t rect;</I> |
| 1055 | /* other members of the structure */ |
| 1056 | }; |
| 1057 | |
| 1058 | </PRE> |
| 1059 | </DD> |
| 1060 | In this example, the application programmer defined a custom structure |
| 1061 | with one ASN.1-derived member (rect). This member is not a reference |
| 1062 | to the Rectangle_t, but an in-place inclusion of the Rectangle_t |
| 1063 | structure. If the freeing is necessary, the usual procedure of freeing |
| 1064 | everything must not be applied to the &rect pointer itself, because |
| 1065 | it does not point to the memory block directly allocated by memory |
| 1066 | allocation routine, but instead lies within such a block allocated |
| 1067 | for my_figure structure. |
| 1068 | |
| 1069 | <P> |
| 1070 | To solve this problem, the free_struct routine has the additional |
| 1071 | argument (besides the intuitive type descriptor and target structure |
| 1072 | pointers), which is the flag specifying whether the outer pointer |
| 1073 | itself must be freed (0, default) or it should be left intact (non-zero |
| 1074 | value). |
| 1075 | |
| 1076 | <P> |
| 1077 | |
| 1078 | <DD><PRE> |
| 1079 | |
| 1080 | /* Rectangle_t is defined within my_figure */ |
| 1081 | struct my_figure *mf = <B>...</B>; |
| 1082 | /* |
| 1083 | * Freeing the Rectangle_td |
| 1084 | * without freeing the mf->rect pointer |
| 1085 | */ |
| 1086 | asn1_DEF_Rectangle->free_struct( |
| 1087 | &asn1_DEF_Rectangle, &mf->rect, <I>1</I> /* !free */); |
| 1088 | |
| 1089 | /* Rectangle_t is a stand-alone pointer */ |
| 1090 | Rectangle_t *rect = <B>...</B>; |
| 1091 | /* |
| 1092 | * Freeing the Rectangle_t |
| 1093 | * and freeing the rect pointer |
| 1094 | */ |
| 1095 | asn1_DEF_Rectangle->free_struct( |
| 1096 | &asn1_DEF_Rectangle, rect, <I>0</I> /* free the pointer too */); |
| 1097 | |
| 1098 | </PRE> |
| 1099 | </DD> |
| 1100 | It is safe to invoke the <I>free_struct</I> function with the target |
| 1101 | structure pointer set to 0 (NULL), the function will do nothing. |
| 1102 | |
| 1103 | <P> |
| 1104 | |
| 1105 | <H2><A NAME="SECTION04000000000000000000"> |
| 1106 | Bibliography</A> |
| 1107 | </H2><DL COMPACT><DD><P></P><DT><A NAME="Dub00">Dub00</A> |
| 1108 | <DD>Olivier Dubuisson - <I>ASN.1 Communication between heterogeneous |
| 1109 | systems</I> - Morgan Kaufmann Publishers, 2000. http://asn1.elibel.tm.fr/en/book/. |
| 1110 | ISBN:0-12-6333361-0. |
| 1111 | <P></P><DT><A NAME="ITU-T_ASN.1">ITU-T/ASN.1</A> |
| 1112 | <DD>ITU-T Study Group 17 - Languages for Telecommunication Systems http://www.itu.int/ITU-T/studygroups/com17/languages/</DL> |
| 1113 | |
| 1114 | <P> |
| 1115 | <BR><HR><H4>Footnotes</H4> |
| 1116 | <DL> |
| 1117 | <DT><A NAME="foot136">... supported</A><A |
| 1118 | HREF="asn1c-usage.html#tex2html1"><SUP>2.1</SUP></A></DT> |
| 1119 | <DD>C++ is ''supported'' too, as long as an object-oriented approach |
| 1120 | is not a definitive factor. |
| 1121 | |
| 1122 | </DD> |
| 1123 | <DT><A NAME="foot315">... this</A><A |
| 1124 | HREF="asn1c-usage.html#tex2html2"><SUP>2.2</SUP></A></DT> |
| 1125 | <DD><I>-fnative-integers</I> compiler option is used to produce basic |
| 1126 | C <I>int</I> types instead of generic INTEGER_t. |
| 1127 | |
| 1128 | </DD> |
| 1129 | <DT><A NAME="foot142">... binary</A><A |
| 1130 | HREF="asn1c-usage.html#tex2html3"><SUP>2.3</SUP></A></DT> |
| 1131 | <DD>BER, CER and DER encodings are binary. However, the XER encoding is |
| 1132 | text (XML) based. |
| 1133 | |
| 1134 | </DD> |
| 1135 | <DT><A NAME="foot316">... specification</A><A |
| 1136 | HREF="asn1c-usage.html#tex2html4"><SUP>2.4</SUP></A></DT> |
| 1137 | <DD>This is probably <B>not</B> what you want to try out right now - |
| 1138 | read through the rest of this chapter to find out about -P option. |
| 1139 | |
| 1140 | </DD> |
| 1141 | <DT><A NAME="foot161">... necessary</A><A |
| 1142 | HREF="asn1c-usage.html#tex2html5"><SUP>2.5</SUP></A></DT> |
| 1143 | <DD>Soon the compiler will be modified to emit the smallest subset of |
| 1144 | necessary files. |
| 1145 | |
| 1146 | </DD> |
| 1147 | <DT><A NAME="foot319">...that simple</A><A |
| 1148 | HREF="asn1c-usage.html#tex2html6"><SUP>2.6</SUP></A></DT> |
| 1149 | <DD>Provided that you've also created a .c file with the <I>int main()</I> |
| 1150 | routine. |
| 1151 | |
| 1152 | </DD> |
| 1153 | <DT><A NAME="foot183">...restartable</A><A |
| 1154 | HREF="asn1c-usage.html#tex2html7"><SUP>2.7</SUP></A></DT> |
| 1155 | <DD>Restartable means that if the decoder encounters the end of the buffer, |
| 1156 | it will fail, but may later be invoked again with the rest of the |
| 1157 | buffer to continue decoding. |
| 1158 | |
| 1159 | </DD> |
| 1160 | <DT><A NAME="foot253">... encoding</A><A |
| 1161 | HREF="asn1c-usage.html#tex2html8"><SUP>2.8</SUP></A></DT> |
| 1162 | <DD>It is actually faster too: the encoder might skip over some computations |
| 1163 | which aren't important for the size determination. |
| 1164 | |
| 1165 | </DD> |
| 1166 | </DL><BR><HR> |
| 1167 | <ADDRESS> |
| 1168 | Lev Walkin |
| 1169 | 2004-08-06 |
| 1170 | </ADDRESS> |
| 1171 | </BODY> |
| 1172 | </HTML> |