Here is a prototype for long DN support in IMM. It is far from complete - for
example I believe there are memory leaks in immutil.c, and thus, in all IMM
tools. The patch only adapts the IMM service and tools. No other service has
been changed, and thus no other service supports long DNs.
Adapting an application to support long DNs is fairly straight forward. You
recompile the application with the preprocessor macro SA_LONGNAME_SOURCE
defined, and fix all the resulting compilation errors. That's it.
gcc -DSA_LONGNAME_SOURCE myapp.c
You will get compilation errors at all places where the application is
accessing the fiels inside the SaNameT type, or where is it using the
SA_MAX_NAME_LENGTH constant. These places have to be fixed. The constant has
been removed, so you will need to use e.g. dynamic memory allocation instead of
using fixed-size buffers. And instead of accessing the fields inside SaNameT,
you need to use the access function saAisNameLend() and saAisNameBorrow().
These functions are used to insert and retrieve a string pointer to/from an
SaNameT object.
Attachment: long_dn_prototype_v1.diff (129.7 kB; text/x-patch)
---
** [tickets:#191] IMM: SaNameT 256 byte size limit and RDN 64 byte size limit.**
**Status:** accepted
**Created:** Tue May 14, 2013 08:12 AM UTC by Anders Bjornerstedt
**Last Updated:** Mon Nov 11, 2013 10:07 AM UTC
**Owner:** Anders Widell
The SaNameT type and in particular its limit in size of 256 bytes
is an aspect of the SAF standard that was, shall we say, not so
well conceived.
The 256 byte limit on SaNameT implies the same limit on DN length.
it is also the reason behind the 64 byte limit on RDN length, if the
RDN attribute is defined on SaStringT.
The SaNameT type is used more or less in the APIs of practically all
SAF services. Thus an enhancement that would try to extend it
length would not just be an enhancement on the IMM service,
but all services.
This discussion topic is intended to probe the possibility of
increasing the size of SaNameT, or of replacing SaNameT with
a type defined in the same way as SaStringT.
There is still a point in having a DN type, that is semantically
distinct from SaStringT, because a DN is in essence the IMM
reference data-type.
One possibility is to continue with SaNameT, but extend both
its struct definition and the size limit.
The "length" member is already defined as SaUint?16T,
which means the length member is not the problem.
Had the SAF standard been defined in C++ we could just create
a subclass to the SaNameT class, but since we are restricted to
the more primitive C language, one has to either create a
completely new type SaNameT_2 or do some kind of "trick".
Changing the type has the big problem that it impacts so many
APIs and in a non backwards compatible way.
So I propose some form of trick.
For example, we can exploit the 16 bit size field, in a way that
is both backwards compatible and forwards compatible.
Assume that if the high order bit of the length feild is set,
then it indicates that this is an extended SaNameT type.
In this case, the value member will not contain the
plain string. Instead it contains first a null terminated
marker string such as "Long SaNameT..." (16 bytes long
including the null termination).
After this string there will be stored a pointer,
which should be aligned on 64/32 bit architectures.
That pointer is a pointer to char*, i.e. it is supposed
to be a pointer to a null terminated string.
The actual size of the string would not be stored in the length
field. For one, it is not needed since we have a null
terminated string. For another, it is prudent not to use the
length field, except the high order bit, to guard against
bugs and illegal use.
This is backwards compatible in the sense that any old API
that currently accepts SaNameT, but that has not been migrated
to a version that understands the extended SaNameT, should
reject the value as being too large. That is it should at least
not just crash. The token string is also there so that naiive
code that ignores the length field and just assumes a null
terminated string in the old SaNameT value array, will find
such a string. Again, it should not crash uncontrollably but
at worst behave in a way that is not correct, but is quickly
recognizable as to its cause.
That "Long SaNameT..." string will be visible and recognizable
for what it is and the bug in the old code can be fixed.
Once an extended SaNameT type is supported in the the immsv,
there is no reason to keep the 64 byte limit on RDN length.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
