Summary: | ASTERISK-08162: inconsistent return checks on handle_request() | ||
Reporter: | Luigi Rizzo (rizzo) | Labels: | |
Date Opened: | 2006-11-21 04:26:33.000-0600 | Date Closed: | 2011-06-07 14:11:57 |
Priority: | Trivial | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | handle_request() can return 0 on success, and a variety (-1, 1 and maybe more) other results from the sub-handlers. The check at the end of sipsock_read() only handles the -1 case as "request failed". Not particularly important since it is just an error message, but i wonder whether we should flag all non-zero return here. | ||
Comments: | By: Olle Johansson (oej) 2006-11-21 06:38:29.000-0600 I don't think this is critical for now, but it's certainly something that needs to be cleaned up. It doesn't cause any bugs as far as I know. At some point, we need to return an ENUM explaining what goes on. By: jmls (jmls) 2007-02-11 03:30:23.000-0600 ping. any further developments on this ? By: Olle Johansson (oej) 2007-02-11 12:19:59.000-0600 As I said: "it's not critical for now". With all these open bugs, I'm focusing on them first. I'm sure that Luigi understands. By: Serge Vecher (serge-v) 2007-02-12 11:04:40.000-0600 assigning to signore Luigi to work on, so the "new" status doesn't attract attention ;) By: Olle Johansson (oej) 2007-05-16 03:56:15 Suspending this bug until we have code. It is not very elegant, but does not cause any bugs in calls at this moment. Let's focus on bugs that cause calls to fail for now, with an overflowing bug tracker. |