mirrors/passt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
passt/lineread.h

33 lines
815 B
C
Raw Normal View History

passt: Relicense to GPL 2.0, or any later version In practical terms, passt doesn't benefit from the additional protection offered by the AGPL over the GPL, because it's not suitable to be executed over a computer network. Further, restricting the distribution under the version 3 of the GPL wouldn't provide any practical advantage either, as long as the passt codebase is concerned, and might cause unnecessary compatibility dilemmas. Change licensing terms to the GNU General Public License Version 2, or any later version, with written permission from all current and past contributors, namely: myself, David Gibson, Laine Stump, Andrea Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-04-05 20:11:44 +02:00
/* SPDX-License-Identifier: GPL-2.0-or-later
Add cleaner line-by-line reading primitives Two places in passt need to read files line by line (one parsing resolv.conf, the other parsing /proc/net/*. They can't use fgets() because in glibc that can allocate memory. Instead they use an implementation line_read() in util.c. This has some problems: * It has two completely separate modes of operation, one buffering and one not, the relation between these and how they're activated is subtle and confusing * At least in non-buffered mode, it will mishandle an empty line, folding them onto the start of the next non-empty line * In non-buffered mode it will use lseek() which prevents using this on non-regular files (we don't need that at present, but it's a surprising limitation) * It has a lot of difficult to read pointer mangling Add a new cleaner implementation of allocation-free line-by-line reading in lineread.c. This one always buffers, using a state structure to keep track of what we need. This is larger than I'd like, but it turns out handling all the edge cases of line-by-line reading in C is surprisingly hard. This just adds the code, subsequent patches will change the existing users of line_read() to the new implementation. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-06-24 04:17:29 +02:00
* Copyright Red Hat
* Author: David Gibson <david@gibson.dropbear.id.au>
*/
#ifndef LINEREAD_H
#define LINEREAD_H
#define LINEREAD_BUFFER_SIZE 8192
/**
* struct lineread - Line reader state
* @fd: File descriptor lines are read from
* @next_line: Offset in @buf of the start of the first line not yet
* returned by lineread_get()
* @count: Number of bytes in @buf read from the file, but not yet
* returned by lineread_get()
* @buf: Buffer storing data read from file.
*/
struct lineread {
lineread: Use ssize_t for line lengths Functions and structures in lineread.c use plain int to record and report the length of lines we receive. This means we truncate the result from read(2) in some circumstances. Use ssize_t to avoid that. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-06-06 12:09:48 +02:00
int fd;
ssize_t next_line;
ssize_t count;
Add cleaner line-by-line reading primitives Two places in passt need to read files line by line (one parsing resolv.conf, the other parsing /proc/net/*. They can't use fgets() because in glibc that can allocate memory. Instead they use an implementation line_read() in util.c. This has some problems: * It has two completely separate modes of operation, one buffering and one not, the relation between these and how they're activated is subtle and confusing * At least in non-buffered mode, it will mishandle an empty line, folding them onto the start of the next non-empty line * In non-buffered mode it will use lseek() which prevents using this on non-regular files (we don't need that at present, but it's a surprising limitation) * It has a lot of difficult to read pointer mangling Add a new cleaner implementation of allocation-free line-by-line reading in lineread.c. This one always buffers, using a state structure to keep track of what we need. This is larger than I'd like, but it turns out handling all the edge cases of line-by-line reading in C is surprisingly hard. This just adds the code, subsequent patches will change the existing users of line_read() to the new implementation. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-06-24 04:17:29 +02:00
/* One extra byte for possible trailing \0 */
char buf[LINEREAD_BUFFER_SIZE+1];
};
void lineread_init(struct lineread *lr, int fd);
lineread: Use ssize_t for line lengths Functions and structures in lineread.c use plain int to record and report the length of lines we receive. This means we truncate the result from read(2) in some circumstances. Use ssize_t to avoid that. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-06-06 12:09:48 +02:00
ssize_t lineread_get(struct lineread *lr, char **line);
Add cleaner line-by-line reading primitives Two places in passt need to read files line by line (one parsing resolv.conf, the other parsing /proc/net/*. They can't use fgets() because in glibc that can allocate memory. Instead they use an implementation line_read() in util.c. This has some problems: * It has two completely separate modes of operation, one buffering and one not, the relation between these and how they're activated is subtle and confusing * At least in non-buffered mode, it will mishandle an empty line, folding them onto the start of the next non-empty line * In non-buffered mode it will use lseek() which prevents using this on non-regular files (we don't need that at present, but it's a surprising limitation) * It has a lot of difficult to read pointer mangling Add a new cleaner implementation of allocation-free line-by-line reading in lineread.c. This one always buffers, using a state structure to keep track of what we need. This is larger than I'd like, but it turns out handling all the edge cases of line-by-line reading in C is surprisingly hard. This just adds the code, subsequent patches will change the existing users of line_read() to the new implementation. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-06-24 04:17:29 +02:00
#endif /* _LINEREAD_H */
Reference in a new issue Copy permalink