[asterisk-dev] [Code Review] Don't read past then end of our int when calling write() in __ast_queue_frame

[wdoekes]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1583/#review4796
-----------------------------------------------------------


Good catch. (And indeed, writing four bytes (or even 8 on some platforms) when only one bit is needed is a waste.)


/branches/1.8/main/channel.c
<https://reviewboard.asterisk.org/r/1583/#comment8962>

    Consider renaming 'blah' to something. Even 'temp' would be better, but in this case perhaps 'onoff' or 'nonzero'.
    
    int buf[variable] is not C90 according to gcc (compile with -pedantic). It will probably work with all gcc's, but other compilers may complain.
    
    Also, I haven't seen this construct anywhere else in the source. Maybe use alloca instead?


- wdoekes


On Nov. 11, 2011, 10:25 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1583/
> -----------------------------------------------------------
> 
> (Updated Nov. 11, 2011, 10:25 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> int blah = 1;
> ...
> write(chan->alertpipe[1], &blah, new_frames * sizeof(blah)) != (new_frames * sizeof(blah)))
> 
> is only valid when new_frames == 1. Otherwise we start reading into adjacent variables declared on the stack. The read end discards what is read, so the values don't matter but it's not a good idea to read past where we want event though new_frames is almost always 1 and should never be large. This patch is basically taken out of kpfleming's eventfd branch, as he mentioned that he remembered fixing it there when I talked to him about this issue.
> 
> Another thing that could be done is to change blah to a char[] here and where we read from the alertpipe. There is no reason to write four bytes when we could just write one, but I can address that in a later patch.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/channel.c 344438 
> 
> Diff: https://reviewboard.asterisk.org/r/1583/diff
> 
> 
> Testing
> -------
> 
> It compiles. Calls still seem to work.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111112/7e8eb639/attachment.htm>