diff options
author | Joseph Myers <josmyers@redhat.com> | 2024-08-21 19:58:14 +0000 |
---|---|---|
committer | Joseph Myers <josmyers@redhat.com> | 2024-08-21 19:58:14 +0000 |
commit | 7f04bb4e49413bd57ac3215f3480b09ae7131968 (patch) | |
tree | 827fee15c0cf9f669522102d7b7840af5432eaff /sysdeps/stub/tcgetattr.c | |
parent | 498ba34ee2472c28cca7b32d132824dbf62651d8 (diff) | |
download | glibc-master.tar.gz glibc-master.tar.xz glibc-master.zip |
There is very little test coverage for getline (only a minimal stdio-common/tstgetln.c which doesn't verify anything about the results of the getline calls). Add some more thorough tests (generally using fopencookie for convenience in testing various cases for what the input and possible errors / EOF in the file read might look like). Note the following regarding testing of error cases: * Nothing is said in the specifications about what if anything might be written into the buffer, and whether it might be reallocated, in error cases. The expectation of the tests (required to avoid memory leaks on error) is that at least on error cases, the invariant that lineptr points to at least n bytes is maintained. * The optional EOVERFLOW error case specified in POSIX, "The number of bytes to be written into the buffer, including the delimiter character (if encountered), would exceed {SSIZE_MAX}.", doesn't seem practically testable, as any case reading so many characters (half the address space) would also be liable to run into allocation failure along (ENOMEM) the way. * If a read error occurs part way through reading an input line, it seems unclear whether a partial line should be returned by getline (avoid input getting lost), which is what glibc does at least in the fopencookie case used in this test, or whether getline should return -1 (error) (so avoiding the program misbehaving by processing a truncated line as if it were complete). (There was a short, inconclusive discussion about this on the Austin Group list on 9-10 November 2014.) * The POSIX specification of getline inherits errors from fgetc. I didn't try to cover fgetc errors systematically, just one example of such an error. Tested for x86_64 and x86.
Diffstat (limited to 'sysdeps/stub/tcgetattr.c')
0 files changed, 0 insertions, 0 deletions