same as in at_readline()

This used to keep only the first character in the EOL sequence whenever keep_eol was true, which I find kind of arbitrary and creates a lot of edge cases to think about. Now you can either have the whole trailing EOL sequence or nothing. If e.g. the EOL is composite (\r\n), individual EOL characters will always be kept.

I didn't change the behavior, but I'm voting to change it s.t.:

• EOL between lines should always be included in their original form - this means keep_eol will be unnecessary and always true
• discard empty lines - which means leading EOLs or multiple in a row will get discarded
  I think this will be much leaner and predictable for the user.

Any arguments against these changes?

how does this pr seperate multiple lines one gets through this function with keep_eol=false? (previously the at_readline would have had left the '/n' in )

-> this function would have returned multiple lines seperated by newline prior to this

I didn't change this, so I don't get what you are referring to. If you mean what I propose to change, then keep_eol will be removed (i.e. will always be true), and the original EOL sequences will stay in, except for multiple in a row. In other words, by my proposal, this function will return a list of non-empty lines separated by the original EOL sequence. Basically just call at_readline_skip_empty(keep_eol=true) untile timeout, OK or ERROR happens. I think this behavior is simpler and in line with what a user would expect.

Moreover, I really can't make up any use-case where throwing out the \r is necessary, and in the current implementation this creates some weird edge-cases, e.g. if a single \r is encountered, but no \n follows it, it is silently dropped.

you changed the behavior of 'at_readline_skip_empty' (at least that is what the comment change to drivers/include/at.h:494
is indicating to no longer return the /n of the /r/n sequence

since this function uses 'at_readline_skip_empty' there might be no line separation ( neither /n nor /r ) while it gets multiple lines.

so without changing this function you changed its behavior ( didn't you ?)

But this wouldn't have happened before either. at_readline_skip_empty(keep_eol=false) (which is only called until the first non-empty line is encountered) would have replaced the trailing \n with \0 anyway. And in case an empty line is returned, a \n or whatever is the last character in EOL is inserted.

Seems that this discussion reinforces my point that the EOL handling of this function needs to be simpified. ;)

I changed this behavior to the one proposed. This also includes some small changes in line parsing -- mainly that response buffer overflow is returned with -ENOBUFS and not silently ignored. I packed these changes in a separate commit.

seems like a leftover

No, I left this in on purpose to have the compile-commands.json of the first build that failes.

why use the test to build the compile-commands.json ?

The test runs through various build configurations, and I want the compile-commands.json of the particular build that failed, without having to re-build that per hand.
Alternatively, I can always build compile-commands whenever a test fails, with that particular build settings.

Ok I changed this so that compile-commands.json is built whenever the test fails.

seem like this could just be int;
at_send_cmd() returns int;
get_lines probaly returns an int to that it turned into an ssize;

this might be the other way around since some of the other functions also seem to return int even though they return size data

atm this seems a little mixed

should be ssize_t everywhere a size is returned but isrpipe_read_timeout() returns int too...

right, so I changed everything like this:

• fn that return 0 or negative error return int
• fn that return a size or negative error return ssize_t
• fn that return a size return size_t

may return size_t ?

return 0 or negative error -> stays int