[asterisk-dev] russell: branch 1.4 r83432 - in /branches/1.4: channels/ include/asterisk/ ma...

Russell Bryant russell at digium.com
Fri Sep 21 13:23:41 CDT 2007

Tony Mountifield wrote:
>> Modified: branches/1.4/channels/chan_h323.c
>> URL:
>> http://svn.digium.com/view/asterisk/branches/1.4/channels/chan_h323.c?view=diff&rev=83432&r1=83431&r2=83432
>> ==============================================================================
>> --- branches/1.4/channels/chan_h323.c (original)
>> +++ branches/1.4/channels/chan_h323.c Fri Sep 21 09:37:20 2007
>> @@ -303,9 +303,9 @@
>>  	free(peer);
>>  }
>> -static int oh323_simulate_dtmf_end(void *data)
>> -{
>> -	struct oh323_pvt *pvt = data;
>> +static int oh323_simulate_dtmf_end(const void *data)
>> +{
>> +	struct oh323_pvt *pvt = (struct oh323_pvt *)data;
>     const struct oh323_pvt *pvt = (const struct oh323_pvt *)data;
> And so on, with many other instances. An arduous task, I know (is that
> what you call a janitor project?), but I'm initially just asking what
> would be pedantically correct.

The issue that gcc 4.2 is complaining about is demonstrated here:

  const char *str = "hi";
  void *ptr = str;

Previously, it did not complaining about taking a pointer that was defined as
const, and assigning it to a void pointer.  Now it does.

Back to your question - yes, it would be pedantically correct to do what you
said.  However, if someone were to try to do it, it's going to cause trouble.
The example you provided is a scheduler callback, and I know those will modify
the object that gets passed in.

This patch got it to compile with the least amount of effort.  However, it may
be more appropriate to go about fixing it up in a different way.  I don't have
time to look at it in any more depth right now ...

Russell Bryant
Software Engineer
Digium, Inc.

More information about the asterisk-dev mailing list