Yes I would also go for (3) now.
I see in this ticket that a few months ago I was for (2).
But I think it is better (if possible) not to tamper with the original
SAF definitions, mainly because it easily explodes into a documentation
nightmare.
I think you should send out a patch for review.
It should go into osaf/libs/saf/include/saAis_B_5_14.
Why 14 for the OpenSAF specific extension?
Lets keep all OpenSAF extensions to SAF APIs have the file extension
numer related to the OpenSAF release.
For some reason we started with 11 for IMM in OpenSAF 4.2.
Lets increment by one for each OpenSAF release where there is any
extension and use the same number for the extension across all
services.
---
** [tickets:#625] osaf: Support constant strings in SAF APIs**
**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Wed Nov 13, 2013 11:25 AM UTC by Anders Widell
**Last Updated:** Tue Mar 04, 2014 03:43 PM UTC
**Owner:** Anders Widell
There is a fundamental problem with the **SaStringT** type as it is currently
defined:
typedef char* SaStringT;
When **SaStringT** is defined like this, it is impossible to declare a string
constant using it. For example, a variable decleared like this:
const SaStringT x;
has the following meaning:
char *const x;
i.e., it is only the pointer **x** that is constant, not the string that it is
pointing to.
There are several possible ways to support constant strings in the SAF APIs:
1) Introduce a new type **SaCharT**, and use **SaCharT** pointers in the API
calls instead of **SaStringT**. Since **SaStringT** is defined as a character
pointer, it should be possible to replace occurrences of **SaStringT** with **
SaCharT* ** without breaking backwards compatibility.
2) Replace the **SaStringT** typedef with a C preprocessor macro, like this:
#define SaStringT char*
3) Intruduce a new type **SaConstStringT**:
typedef const char* SaConstStringT;
The proposal is to go for 3), and to begin with only define the new type. The
new type can later on be used when defining new APIs.
---
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.------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
