Hi, On Mon, Sep 19, 2011 at 9:42 AM, Ronny Meeus <[email protected]> wrote: > On Mon, Sep 19, 2011 at 9:25 AM, <[email protected]> wrote: >>> From: [email protected] [mailto:[email protected]] >>> On Behalf Of Philippe Gerum >>> Sent: Sunday, September 18, 2011 5:37 PM >>> ... >>> Actually, we used to follow strictly the pSOS convention for this until >>> 2.4.x, at which point we moved to name strings precisely because >>> non-null terminated char[4] arrays would break the registry, the way you >>> described. This is one of the rare situations where mimicking a useless >>> limitation of the original API may be challenged by usability concerns >>> in the new environment, and usability won in that case. The problem >>> mostly comes from the fact that char[4] is automatically convertible to >>> const char *, so we have no warning/error leading us to check the >>> potentially problematic call sites. >>> >>> The concern about moving back to char[4] arrays - null-terminated if >>> shorter - is for people who currently assign strings longer than 4 >>> characters to name their objects. What could be done, is providing a >>> build switch to select the accepted input, like >>> --disable-psos-long-names to turn on char[4] interpretation. >> >> While I would prefer the switch --enable-psos-long-names, this sounds okay >> to me, the more so as it is more than people who use the pSOS skin without >> obeying pSOS rules deserve. >> -- [..] >> > > Another option would be to introduce a run-time switch. > The default behavior could be that long names are supported and if the > "enable_short_names()" function is called, all names will the cut at 4 > characters. > The advantage of this dynamic switch is that different applications > using the same library can use the mode they prefer.
I would also be in favor of a runtime setting, rather than a compile-time one. One cannot assume that all PSOS applications on a system follow the same rules, or that there cannot be a mix of 'legacy' PSOS applications and 'xenomai-style' ones. According to me, a library should support all these uses. Best regards, Thomas _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
