| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
OBJ_get0_data(3) and OBJ_length(3). Document them.
Feedback and OK tb@.
|
|
|
|
|
| |
This is no longer public API. Also remove some comments about i2c and c2i
functions being intentionally undocumented since they are no longer public.
|
|
|
|
|
|
|
| |
we no longer have, focus on what our implementation now does, but
keep short warnings in how far other implementations might be more
fragile. Some improvements to wordings and clarity while here.
OK tb@
|
|
|
|
| |
discussed with jsing@
|
|
|
|
| |
while here, add a few STANDARDS references
|
|
|
|
|
| |
to some parameters of some functions. Update the documentation.
Add a few additional missing const qualifiers while here.
|
|
|
|
| |
on the web, so fix up SSLeay HISTORY accordingly
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Better one-line description.
Specify the correct header file.
Same parameter names as in ASN1_item_d2i(3).
Lots of new information.
The ASN1_OBJECT interfaces appear specifically designed to maximize
the number and subtlety of traps, maybe in order to trap the wary
along with the unwary. All the quirks, caveats, and bugs of
ASN1_item_d2i(3) apply, and there are three additional ones on top
in this page.
It looks like that design approach was so successful that the designers
managed to trap even themselves: see the new BUGS section.
|
| |
|
| |
|
| |
|
|
|