[asterisk-dev] [asterisk-commits] eliel: branch group/appdocsxml r151893 - in /team/group/appdocsxml: include/a...

[Eliel Sardañons]

Kevin,
Maybe we can discuss if it makes sense to do those typedefs (ast_xml_text
and ast_xml_attr). But the casting is being done on ->AST_XML_NAME (actually
on node->name this is because of a signedness warning) and not when working
with the typedefs ast_xml_attr and ast_xml_text.
->name is defined as xmlChar * (libxml2 implementation, maybe 'unsigned char
*' ??? didn't check it...).

To avoid this inline casting we can create a MACRO definition like NAME(a)
((const char *)a->name) and move all to this type of coding like:
NEXT(a) (a->next)
PREV(a) (a->prev)
CHILD(a) (a->children)
(I have started coding with this approach but I think is harder to
understand (??))

Hope this help you understand the problem to find (if it exists) a better
solution.

Eliel

On Tue, Oct 28, 2008 at 10:32 AM, Kevin P. Fleming <kpfleming at digium.com>wrote:

> SVN commits to the Asterisk project wrote:
>
> > - Cast to (const char *) where we are talking about a constant value.
>
> It concerns me a bit that all this casting is being done; you've
> typedef'd 'char' and 'const char' with ast_xml_attr and ast_xml_text
> names, and then nearly every time you use the variables defined with
> these types you have to cast them to their underlying types.
>
> What is the value of having the typedefs in this situation?
>
> --
> Kevin P. Fleming
> Director of Software Technologies
> Digium, Inc. - "The Genuine Asterisk Experience" (TM)
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Eliel Sardañons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20081028/d1fab666/attachment.htm