That is a good question. In the prototype, I simply wrote them as inline
functions in the header file, but that is probably not a good option for the
final solution. I can see three alternatives:
* Create a new library libSaAis (which currently doesn't exist)
* Add them some existing library, e.g. libSaImmOm
* Add them as samles, as you suggest. maybe to immutils?
---
** [tickets:#191] IMM: SaNameT 256 byte size limit and RDN 64 byte size limit.**
**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Tue May 14, 2013 08:12 AM UTC by Anders Bjornerstedt
**Last Updated:** Thu Mar 13, 2014 02:54 PM 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 opensaf-tickets@lists.sourceforge.net 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.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
