Hi Alastair, Sorry, for not making myself clear. What I tried to say simply was, "Why should axutil_string_get_buffer return a CONST type?". My argument is, if it should be used as a non-CONST, then it should rather not be a CONST, instead of making the API preserve it's CONST-ness. See my comments inline.
> Hi Senaka. > > Just because you can doesn't mean you should. If there is a reason that > the return object is const then this property should be preserved. If > the response should not be const then a different method other than > casting away the const should be done. I.e. Removing the const nature > of the response object from the function. Agreed. > > Also, this seems to contradict an earlier statement about memory > ownership and the const convention. I think we haven't paid much attention on RETURN-TYPES. I'm not sure about the extent to which modifications in code would be required. However, if we could enforce a convention, I'm +1 for that. I have cc'd this message to the dev-list. Regards, Senaka > > Alastair > > This e-mail and any attachments are intended solely for the use of the > intended recipient(s) and may contain legally privileged, proprietary > and/or confidential information. Any use, disclosure, dissemination, > distribution or copying of this e-mail and any attachments for any > purposes that have not been specifically authorized by the sender is > strictly prohibited. If you are not the intended recipient, please > immediately notify the sender by reply e-mail and permanently delete all > copies and attachments. > > The entire content of this e-mail is for "information purposes" only and > should not be relied upon by the recipient in any way unless otherwise > confirmed in writing by way of letter or facsimile. > > -----Original Message----- > From: Senaka Fernando [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 09, 2008 9:13 PM > To: Apache AXIS C User List > Subject: Re: [Axis2C] Casting away const > >> It looks to me it is a bug. axiom_attribute_get_value should be >> returning a const axis2_char_t. > > Yes, I think you are correct here. But, even if we do return a const, > casting can do the trick isn't it? Take a situation where we return a > non-const ref through a const return statement. Would a box-in > conversion preserve the const-ness? > > Regards, > Senaka > >> >> Samisa... >> >> Alastair FETTES wrote: >>> >>> Axis2C Developers: >>> >>> There seems to be a fundamental problem with functions that return >>> values of type axis2_chart_t*. We have only investigated a couple of > >>> them but it appears that const values are being casted away in some >>> instances. Please view the following example: >>> >>> <snippet> >>> AXIS2_EXTERN >>> axis2_char_t* >>> axiom_attribute_get_value( >>> axiom_attribute_t * attribute, >>> const axutil_env_t * env) >>> { >>> if (attribute->value) >>> { >>> return (axis2_char_t *) >>> axutil_string_get_buffer(attribute->value, env); >>> } >>> return NULL; >>> } >>> </snippet> >>> >>> Note that the return value of axiom_attribute_get_value is a >>> NON-const axis2_char_t*. Note the cast on the return value of >>> function axutil_string_get_buffer. Here is the declaration of >>> axutil_string_get_buffer. >>> >>> <snippet> >>> AXIS2_EXTERN >>> const axis2_char_t* >>> axutil_string_get_buffer( >>> const struct axutil_string *string, >>> const axutil_env_t * env); >>> </snippet> >>> >>> Note that the return value is a CONST axis2_char_t*. The const >>> attribute of this pointer is being removed via the cast. >>> >>> Is this expected functionality? If not I suggest you research all >>> functions that return axis2_char_t*. >>> >>> Regards. >>> >>> Alastair Fettes >>> >>> This e-mail and any attachments are intended solely for the use of >>> the intended recipient(s) and may contain legally privileged, >>> proprietary and/or confidential information. Any use, disclosure, >>> dissemination, distribution or copying of this e-mail and any >>> attachments for any purposes that have not been specifically >>> authorized by the sender is strictly prohibited. If you are not the >>> intended recipient, please immediately notify the sender by reply >>> e-mail and permanently delete all copies and attachments. >>> >>> The entire content of this e-mail is for "information purposes" only >>> and should not be relied upon by the recipient in any way unless >>> otherwise confirmed in writing by way of letter or facsimile. >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date: >>> 1/8/2008 1:38 PM >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
