Retrieves the full version number of the C-library, composed as MAJOR.MINORplPATCH (the major and minor version numbers and the patchlevel are integers).
If set to true, the library will assume that each input file consists of exactly one email message or newsgroup posting. After finding encoded data within a file, the scanner will not continue to look for more data below. This strategy can save a lot of time, but has the drawback that files also cannot be checked for completeness – since the scanner does not look for “end” lines, we don’t notice them missing. This flag does not have any effect on MIME multipart messages, which are always scanned to the end. Actually, with this flag set, the scanner becomes more MIME-compliant.
The library evaluates information found in the part’s “Subject” header line if available. The heuristics here are versatile, but cannot be guaranteed to be completely failure-proof. If false information is derived, the parts will be ordered and grouped wrong, resulting in wrong decoding. If the “dumbness” is set to true, the code to derive a part number is disabled; it will then be assumed that all parts within a group appear in correct order: the first one is assigned number 1 etc. However, part numbers found in MIME-headers are still. A dumbness of 2 also switches off the code to select a unique identifier from the subject line. This does still work with single-part files and might work with multi-part files, as long as they’re in correct order and not mixed. The filename is found on the first part and then passed on to the following parts.
This option only takes effect for files scanned afterwards.
Series of multi-part postings on the Usenet usually have subject lines like “You must see this! [1/3] (2/4)”. How to parse this information? Is this the second part of four in a series of three postings, or is it the first of three parts and the second in a series of four postings? The library cannot know, and simply gives numbers in () parentheses precedence over number in [] brackets. If this assumption fails, the parts will be grouped and ordered completely wrong. Setting the “bracket policy” to true changes this precedence. If now both parentheses and brackets are present, the numbers within brackets will be evaluated first.
This option only takes effect for files scanned afterwards.
If set to false, the Message Callback will not be bothered with messages of level UUMSG_MESSAGE or UUMSG_NOTE. The default is to generate these messages.
By default, the library refuses to decode incomplete files and generates errors. But if switched into “desperate mode” these kinds of errors are ignored, and all available data is decoded. The usefulness of the resulting corrupt file depends on the type of the file.
If set to true, the library will ignore email messages and news postings which were sent as “Reply”, since they are less likely to feature useful data.
When the decoder finds that the target file already exists, it is simply overwritten silently by default. If this option is set to false, the decoder fails instead, generating a UURET_EXIST error.
Without setting this option, files are decoded to the current directory. This “save path” is handled as prefix to each filename. Because the library does not know about directory layouts, the resulting filename is simply the concatenation of the save path and the target file, meaning that the path must include a final directory separator (slash, backslash, or whatever).
Usually, the decoder tries to restore the file mode found on the “begin” line of uuencoded and xxencoded files. This is turned off if this option is set to true.
If set to true, all messages will be prefixed with the exact sourcecode location (filename and line number) where they were created. It might be useful if this is not clear from context.
This “option” can be queried after an operation failed with UURET_IOERR and returns the errno value that originally caused the problem. The “real” value of this variable might already be obscured by secondary problems.
Returns the progress object. This would only make sense in multi-threaded environments where the decoder runs in one thread and is controlled from another.
If this flag is true, plain text files will be presented for “decoding”. This includes non-decodable messages as well as plain-text parts from MIME multipart messages. Since they usually don’t have associated filenames, a unique name will be created from a sequential four-digit number.
Whether to use the plain-text preamble and epilogue from MIME multipart messages. The standard defines they’re supposed to be ignored, so there’s no real reason to set this option.
Support for tiny Base64 data. If set to false, the scanner does not recognize stand-alone Base64 encoded data with less than 3 lines. The problem is that in some cases plain text might be misinterpreted as Base64 data, since, for example, any four-character alphanumerical string like “Argh” appearing on a line of its own is valid Base64 data. Since encoded files are usually longer, and there is considerable confusion about erroneous Base64 detection, this option is false by default. There’s probably no need to present this option separately to the user. It’s reasonable to associate it with the “desperate mode” described above.
Note that this option only affects stand-alone data. Input from Mime messages with the encoding type correctly specified in the “Content-Transfer-Encoding” header is always evaluated.
There is also no problem with encoding types different than Base64, since they have an explicit notion of the beginning and end of a file, and no danger of misinterpretation exists.
When encoding into a file on the local disk, the target files usually receive an extension composed of the three-digit part number. This may be considered inappropriate for single-part files. If this option is set, its value is attached to the base file name as extension for the target file. A dot ‘.’ is inserted automatically. When using uuencoding, a sensible value might be “uue”.
This option does not alter the behaviour on multi-part files, where the individual parts always receive the three-digit part number as extension.
If true, input files are deleted if data was successfully decoded from them. Be careful with this option, as the library does not care if the file contains any other useful information besides the decoded data. And it also does not and can not check the integrity of the decoded file. Therefore, if in doubt of the incoming data, you should do a confidence check first and then delete the relevant input files afterwards.
Makes the library behave more MIME-compliant. Normally, some liberties are taken with seemingly MIME files in order to find encoded data within it, therefore also finding files within broken MIME messages. If this option is set to 1, the library is more strict in its handling of MIME files, and will for example not allow Base 64 data outside of properly tagged subparts, and will not accept “random” encoded data.
You can also set the value of this option to 2 to enforce strict MIME adherence. If the option is 1, the library will still look into plain text attachments and try to find encoded data within it. This causes for example uuencoded files that were then sent in a MIME envelope to be recognized. With an option value of 2, the library won’t even do that, trusting all MIME header information.
