AVR Freaks

Note that the AT Command Teminator is just CR - not CRLF.

As this syntax doesn't have a termination character 

Yes, it does - the CRLF marks the end of the response.

Or, in fact, any other GSM modem.

Or, in fact, anything which uses AT Commands!

so there's tons of code out on the internet showing how to do this

Sadly, an awful lot of it makes the fundamental mistake of failing to properly handle responses - but the OP does seem to be onto that one!

As most of it is "above the hardware" it doesn't really matter whether such examples are for AVR or some other micro

Or, as noted, some other device using AT Commands.

Clearly, it's not always going to be the third.

This is where studying V.250 - and the module's AT Command manual - would help to understand the overall structure of the protocol.

In particular, note that there are Intermediate responses, and Terminal (or "Terminating" or "Final") responses.

So you need to keep "collecting" responses until you reach the Terminal response - the OK or ERROR.

As noted in the links I posted earlier, a State Machine can help here ...

EDIT

Also beware of Unsolicited responses...

Yes - it was an aside.

But, as I said, it is the Command terminator - which is distinct from the Response Formatting sequence

Well, the description certainly sounds like exactly what the OP needs:

EDIT

And it does, indeed, seem to be using a State Machine

As I say all this stuff has been done before. The commands and the likely responses (can be multiple with different formats!) are well known. Most people employ some kind of "state machine". So, for example for the command:

AT+CGATT?{0D}{0A}{0D}{0A}+CGATT: 1{0D}{0A}{0D}{0A}OK{0D}{0A}

It may well be that it may respond "+GGATT:1" and then "OK" but suppose it might also say "ERROR" here. That is just one line of response not two. So for every command you really need to analyze all the potential responses and be ready for them. Of course if you don't see 'E' but '+' as the first character on the first line of response you can be pretty sure already it's not going to turn out to be ERROR. This is why you can handle this with a state machine.

On the whole "Hayes compatible" modems don't differ - a lot of this stuff is as old as the hills and folks have been capturing the responses for all the commands for years. That's why you should be able to find existing code that already knows all this stuff - no real point in reinventing the wheel.

The only problem as Andy alluded to is that you do not know the provenance of code you find on the internet. It may be a work of genius, it may be a steaming pile of dung. Usually it's pretty obvious from the initial "quality" of the code which you are looking at though.