Sasha Khapyorsky wrote:
<snip...>
>> @@ -1080,7 +1082,8 @@ void osm_dump_node_record(IN osm_log_t * p_log,
>>
>> /**********************************************************************
>>
>> **********************************************************************/
>> -void osm_dump_path_record(IN osm_log_t * p_log, IN const
>> ib_path_rec_t * p_pr, +void osm_dump_path_record(IN osm_log_t *
>> const p_log, + IN const
>> ib_path_rec_t * const p_pr, IN
>> const osm_log_level_t log_level) {
>> if (osm_log_is_active(p_log, log_level)) {
>> @@ -1106,9 +1109,9 @@ void osm_dump_path_record(IN osm_log_t *
>> p_log, IN const ib_path_rec_t * p_pr,
>> "\t\t\t\tresv2...................0x%X\n"
>> "\t\t\t\tresv3...................0x%X\n",
>> cl_ntoh64(p_pr->service_id), - inet_ntop(AF_INET6,
>> p_pr->dgid.raw,
>> gid_str, + inet_ntop(AF_INET6, (void*)p_pr->dgid.raw,
>> gid_str,
>
> And why is such casting(s) needed?
The '(void *)' on inet_ntop() was the only way I could get the MS compiler
warnings about differing const types to go away;
(const void *) failed.
Since suppression of information is the preferred modus operandi, I'll see if I
can figure out a way to suppress the warning.
>
> Also wouldn't it be simpler to remove 'const' in "type * const var"
> function parameter definitions? This restricts only value of a pointer
> (not structure content), and since function parameters are passed by
> values such restriction is only related to a function implementation
> and actually meanless in sense of API. Thoughts?
I'm just the messenger here, making the function match the prototype.
Fine by me if you choose to change both.
Stan.
_______________________________________________
ofw mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
