>
> > diff --git a/gatchat/gatresult.c b/gatchat/gatresult.c
> > index 8a6dfae..c919305 100644
> > --- a/gatchat/gatresult.c
> > +++ b/gatchat/gatresult.c
> > @@ -39,6 +39,11 @@ void g_at_result_iter_init(GAtResultIter *iter,
> > GAtResult *result)
> > iter->line_pos = 0;
> > }
> >
> > +gboolean g_at_result_iter_eol(GAtResultIter *iter)
> > +{
> > + return iter->line_pos >= strlen(iter->l->data);
> > +}
> > +
>
> And I pretty much don't see the need for this. It doesn't really help
> you here.
No, this function can help to ignore unsolicited response properly.
I think the difference between solicited and unsolicited CGREG is the number
of parameters after +CGREG:, so it would be nice if we have a utility
function to know we are at the end of AT return string.
This is what we want to parse the state info from the solicited response:
+CGREG: <n>, <state>, <lac>, <ci>
but in a race condition, we received this unsolicited response from Huawei
modem:
+CGREG: <state>, <lac>, <ci>
In your proposed patch, it bypass the unsolicited response only if the 2nd
number after +CGREG: is not single digit, however if the lac is single
digit, we will still get the wrong state number.
So I still believe we should check whether we are at the end of the return
string before parsing the unquoted lac and ci. If we are at the end of the
string, then this is a unsolicited code and we should ignore it. How do you
think?
> > gboolean g_at_result_iter_next(GAtResultIter *iter, const char *prefix)
> > {
> > char *line;
> > diff --git a/gatchat/gatresult.h b/gatchat/gatresult.h
> > index a74741f..33c0b2c 100644
> > --- a/gatchat/gatresult.h
> > +++ b/gatchat/gatresult.h
> > @@ -46,6 +46,7 @@ struct _GAtResultIter {
> > typedef struct _GAtResultIter GAtResultIter;
> >
> > void g_at_result_iter_init(GAtResultIter *iter, GAtResult *result);
> > +gboolean g_at_result_iter_eol(GAtResultIter *iter);
> >
> > gboolean g_at_result_iter_next(GAtResultIter *iter, const char
> > *prefix);
> > gboolean g_at_result_iter_open_list(GAtResultIter *iter);
>
> Anyhow, can you please try the attached patch and see if it solves your
> problems.
>
> Regards,
> -Denis
>
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
