THIS IS A TEST INSTANCE ONLY! REPOSITORIES CAN BE DELETED AT ANY TIME!

Git Source Code Mirror - This is a publish-only repository and all pull requests are ignored. Please follow Documentation/SubmittingPatches procedure for any of your improvements.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

pkt-line.h 7.9KB

pkt-line: share buffer/descriptor reading implementation The packet_read function reads from a descriptor. The packet_get_line function is similar, but reads from an in-memory buffer, and uses a completely separate implementation. This patch teaches the generic packet_read function to accept either source, and we can do away with packet_get_line's implementation. There are two other differences to account for between the old and new functions. The first is that we used to read into a strbuf, but now read into a fixed size buffer. The only two callers are fine with that, and in fact it simplifies their code, since they can use the same static-buffer interface as the rest of the packet_read_line callers (and we provide a similar convenience wrapper for reading from a buffer rather than a descriptor). This is technically an externally-visible behavior change in that we used to accept arbitrary sized packets up to 65532 bytes, and now cap out at LARGE_PACKET_MAX, 65520. In practice this doesn't matter, as we use it only for parsing smart-http headers (of which there is exactly one defined, and it is small and fixed-size). And any extension headers would be breaking the protocol to go over LARGE_PACKET_MAX anyway. The other difference is that packet_get_line would return on error rather than dying. However, both callers of packet_get_line are actually improved by dying. The first caller does its own error checking, but we can drop that; as a result, we'll actually get more specific reporting about protocol breakage when packet_read dies internally. The only downside is that packet_read will not print the smart-http URL that failed, but that's not a big deal; anybody not debugging can already see the remote's URL already, and anybody debugging would want to run with GIT_CURL_VERBOSE anyway to see way more information. The second caller, which is just trying to skip past any extra smart-http headers (of which there are none defined, but which we allow to keep room for future expansion), did not error check at all. As a result, it would treat an error just like a flush packet. The resulting mess would generally cause an error later in get_remote_heads, but now we get error reporting much closer to the source of the problem. Brown-paper-bag-fixes-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: share buffer/descriptor reading implementation The packet_read function reads from a descriptor. The packet_get_line function is similar, but reads from an in-memory buffer, and uses a completely separate implementation. This patch teaches the generic packet_read function to accept either source, and we can do away with packet_get_line's implementation. There are two other differences to account for between the old and new functions. The first is that we used to read into a strbuf, but now read into a fixed size buffer. The only two callers are fine with that, and in fact it simplifies their code, since they can use the same static-buffer interface as the rest of the packet_read_line callers (and we provide a similar convenience wrapper for reading from a buffer rather than a descriptor). This is technically an externally-visible behavior change in that we used to accept arbitrary sized packets up to 65532 bytes, and now cap out at LARGE_PACKET_MAX, 65520. In practice this doesn't matter, as we use it only for parsing smart-http headers (of which there is exactly one defined, and it is small and fixed-size). And any extension headers would be breaking the protocol to go over LARGE_PACKET_MAX anyway. The other difference is that packet_get_line would return on error rather than dying. However, both callers of packet_get_line are actually improved by dying. The first caller does its own error checking, but we can drop that; as a result, we'll actually get more specific reporting about protocol breakage when packet_read dies internally. The only downside is that packet_read will not print the smart-http URL that failed, but that's not a big deal; anybody not debugging can already see the remote's URL already, and anybody debugging would want to run with GIT_CURL_VERBOSE anyway to see way more information. The second caller, which is just trying to skip past any extra smart-http headers (of which there are none defined, but which we allow to keep room for future expansion), did not error check at all. As a result, it would treat an error just like a flush packet. The resulting mess would generally cause an error later in get_remote_heads, but now we get error reporting much closer to the source of the problem. Brown-paper-bag-fixes-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: teach packet_read_line to chomp newlines The packets sent during ref negotiation are all terminated by newline; even though the code to chomp these newlines is short, we end up doing it in a lot of places. This patch teaches packet_read_line to auto-chomp the trailing newline; this lets us get rid of a lot of inline chomping code. As a result, some call-sites which are not reading line-oriented data (e.g., when reading chunks of packfiles alongside sideband) transition away from packet_read_line to the generic packet_read interface. This patch converts all of the existing callsites. Since the function signature of packet_read_line does not change (but its behavior does), there is a possibility of new callsites being introduced in later commits, silently introducing an incompatibility. However, since a later patch in this series will change the signature, such a commit would have to be merged directly into this commit, not to the tip of the series; we can therefore ignore the issue. This is an internal cleanup and should produce no change of behavior in the normal case. However, there is one corner case to note. Callers of packet_read_line have never been able to tell the difference between a flush packet ("0000") and an empty packet ("0004"), as both cause packet_read_line to return a length of 0. Readers treat them identically, even though Documentation/technical/protocol-common.txt says we must not; it also says that implementations should not send an empty pkt-line. By stripping out the newline before the result gets to the caller, we will now treat the newline-only packet ("0005\n") the same as an empty packet, which in turn gets treated like a flush packet. In practice this doesn't matter, as neither empty nor newline-only packets are part of git's protocols (at least not for the line-oriented bits, and readers who are not expecting line-oriented packets will be calling packet_read directly, anyway). But even if we do decide to care about the distinction later, it is orthogonal to this patch. The right place to tighten would be to stop treating empty packets as flush packets, and this change does not make doing so any harder. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: share buffer/descriptor reading implementation The packet_read function reads from a descriptor. The packet_get_line function is similar, but reads from an in-memory buffer, and uses a completely separate implementation. This patch teaches the generic packet_read function to accept either source, and we can do away with packet_get_line's implementation. There are two other differences to account for between the old and new functions. The first is that we used to read into a strbuf, but now read into a fixed size buffer. The only two callers are fine with that, and in fact it simplifies their code, since they can use the same static-buffer interface as the rest of the packet_read_line callers (and we provide a similar convenience wrapper for reading from a buffer rather than a descriptor). This is technically an externally-visible behavior change in that we used to accept arbitrary sized packets up to 65532 bytes, and now cap out at LARGE_PACKET_MAX, 65520. In practice this doesn't matter, as we use it only for parsing smart-http headers (of which there is exactly one defined, and it is small and fixed-size). And any extension headers would be breaking the protocol to go over LARGE_PACKET_MAX anyway. The other difference is that packet_get_line would return on error rather than dying. However, both callers of packet_get_line are actually improved by dying. The first caller does its own error checking, but we can drop that; as a result, we'll actually get more specific reporting about protocol breakage when packet_read dies internally. The only downside is that packet_read will not print the smart-http URL that failed, but that's not a big deal; anybody not debugging can already see the remote's URL already, and anybody debugging would want to run with GIT_CURL_VERBOSE anyway to see way more information. The second caller, which is just trying to skip past any extra smart-http headers (of which there are none defined, but which we allow to keep room for future expansion), did not error check at all. As a result, it would treat an error just like a flush packet. The resulting mess would generally cause an error later in get_remote_heads, but now we get error reporting much closer to the source of the problem. Brown-paper-bag-fixes-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: teach packet_read_line to chomp newlines The packets sent during ref negotiation are all terminated by newline; even though the code to chomp these newlines is short, we end up doing it in a lot of places. This patch teaches packet_read_line to auto-chomp the trailing newline; this lets us get rid of a lot of inline chomping code. As a result, some call-sites which are not reading line-oriented data (e.g., when reading chunks of packfiles alongside sideband) transition away from packet_read_line to the generic packet_read interface. This patch converts all of the existing callsites. Since the function signature of packet_read_line does not change (but its behavior does), there is a possibility of new callsites being introduced in later commits, silently introducing an incompatibility. However, since a later patch in this series will change the signature, such a commit would have to be merged directly into this commit, not to the tip of the series; we can therefore ignore the issue. This is an internal cleanup and should produce no change of behavior in the normal case. However, there is one corner case to note. Callers of packet_read_line have never been able to tell the difference between a flush packet ("0000") and an empty packet ("0004"), as both cause packet_read_line to return a length of 0. Readers treat them identically, even though Documentation/technical/protocol-common.txt says we must not; it also says that implementations should not send an empty pkt-line. By stripping out the newline before the result gets to the caller, we will now treat the newline-only packet ("0005\n") the same as an empty packet, which in turn gets treated like a flush packet. In practice this doesn't matter, as neither empty nor newline-only packets are part of git's protocols (at least not for the line-oriented bits, and readers who are not expecting line-oriented packets will be calling packet_read directly, anyway). But even if we do decide to care about the distinction later, it is orthogonal to this patch. The right place to tighten would be to stop treating empty packets as flush packets, and this change does not make doing so any harder. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: provide a LARGE_PACKET_MAX static buffer Most of the callers of packet_read_line just read into a static 1000-byte buffer (callers which handle arbitrary binary data already use LARGE_PACKET_MAX). This works fine in practice, because: 1. The only variable-sized data in these lines is a ref name, and refs tend to be a lot shorter than 1000 characters. 2. When sending ref lines, git-core always limits itself to 1000 byte packets. However, the only limit given in the protocol specification in Documentation/technical/protocol-common.txt is LARGE_PACKET_MAX; the 1000 byte limit is mentioned only in pack-protocol.txt, and then only describing what we write, not as a specific limit for readers. This patch lets us bump the 1000-byte limit to LARGE_PACKET_MAX. Even though git-core will never write a packet where this makes a difference, there are two good reasons to do this: 1. Other git implementations may have followed protocol-common.txt and used a larger maximum size. We don't bump into it in practice because it would involve very long ref names. 2. We may want to increase the 1000-byte limit one day. Since packets are transferred before any capabilities, it's difficult to do this in a backwards-compatible way. But if we bump the size of buffer the readers can handle, eventually older versions of git will be obsolete enough that we can justify bumping the writers, as well. We don't have plans to do this anytime soon, but there is no reason not to start the clock ticking now. Just bumping all of the reading bufs to LARGE_PACKET_MAX would waste memory. Instead, since most readers just read into a temporary buffer anyway, let's provide a single static buffer that all callers can use. We can further wrap this detail away by having the packet_read_line wrapper just use the buffer transparently and return a pointer to the static storage. That covers most of the cases, and the remaining ones already read into their own LARGE_PACKET_MAX buffers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: teach packet_read_line to chomp newlines The packets sent during ref negotiation are all terminated by newline; even though the code to chomp these newlines is short, we end up doing it in a lot of places. This patch teaches packet_read_line to auto-chomp the trailing newline; this lets us get rid of a lot of inline chomping code. As a result, some call-sites which are not reading line-oriented data (e.g., when reading chunks of packfiles alongside sideband) transition away from packet_read_line to the generic packet_read interface. This patch converts all of the existing callsites. Since the function signature of packet_read_line does not change (but its behavior does), there is a possibility of new callsites being introduced in later commits, silently introducing an incompatibility. However, since a later patch in this series will change the signature, such a commit would have to be merged directly into this commit, not to the tip of the series; we can therefore ignore the issue. This is an internal cleanup and should produce no change of behavior in the normal case. However, there is one corner case to note. Callers of packet_read_line have never been able to tell the difference between a flush packet ("0000") and an empty packet ("0004"), as both cause packet_read_line to return a length of 0. Readers treat them identically, even though Documentation/technical/protocol-common.txt says we must not; it also says that implementations should not send an empty pkt-line. By stripping out the newline before the result gets to the caller, we will now treat the newline-only packet ("0005\n") the same as an empty packet, which in turn gets treated like a flush packet. In practice this doesn't matter, as neither empty nor newline-only packets are part of git's protocols (at least not for the line-oriented bits, and readers who are not expecting line-oriented packets will be calling packet_read directly, anyway). But even if we do decide to care about the distinction later, it is orthogonal to this patch. The right place to tighten would be to stop treating empty packets as flush packets, and this change does not make doing so any harder. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: provide a LARGE_PACKET_MAX static buffer Most of the callers of packet_read_line just read into a static 1000-byte buffer (callers which handle arbitrary binary data already use LARGE_PACKET_MAX). This works fine in practice, because: 1. The only variable-sized data in these lines is a ref name, and refs tend to be a lot shorter than 1000 characters. 2. When sending ref lines, git-core always limits itself to 1000 byte packets. However, the only limit given in the protocol specification in Documentation/technical/protocol-common.txt is LARGE_PACKET_MAX; the 1000 byte limit is mentioned only in pack-protocol.txt, and then only describing what we write, not as a specific limit for readers. This patch lets us bump the 1000-byte limit to LARGE_PACKET_MAX. Even though git-core will never write a packet where this makes a difference, there are two good reasons to do this: 1. Other git implementations may have followed protocol-common.txt and used a larger maximum size. We don't bump into it in practice because it would involve very long ref names. 2. We may want to increase the 1000-byte limit one day. Since packets are transferred before any capabilities, it's difficult to do this in a backwards-compatible way. But if we bump the size of buffer the readers can handle, eventually older versions of git will be obsolete enough that we can justify bumping the writers, as well. We don't have plans to do this anytime soon, but there is no reason not to start the clock ticking now. Just bumping all of the reading bufs to LARGE_PACKET_MAX would waste memory. Instead, since most readers just read into a temporary buffer anyway, let's provide a single static buffer that all callers can use. We can further wrap this detail away by having the packet_read_line wrapper just use the buffer transparently and return a pointer to the static storage. That covers most of the cases, and the remaining ones already read into their own LARGE_PACKET_MAX buffers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: share buffer/descriptor reading implementation The packet_read function reads from a descriptor. The packet_get_line function is similar, but reads from an in-memory buffer, and uses a completely separate implementation. This patch teaches the generic packet_read function to accept either source, and we can do away with packet_get_line's implementation. There are two other differences to account for between the old and new functions. The first is that we used to read into a strbuf, but now read into a fixed size buffer. The only two callers are fine with that, and in fact it simplifies their code, since they can use the same static-buffer interface as the rest of the packet_read_line callers (and we provide a similar convenience wrapper for reading from a buffer rather than a descriptor). This is technically an externally-visible behavior change in that we used to accept arbitrary sized packets up to 65532 bytes, and now cap out at LARGE_PACKET_MAX, 65520. In practice this doesn't matter, as we use it only for parsing smart-http headers (of which there is exactly one defined, and it is small and fixed-size). And any extension headers would be breaking the protocol to go over LARGE_PACKET_MAX anyway. The other difference is that packet_get_line would return on error rather than dying. However, both callers of packet_get_line are actually improved by dying. The first caller does its own error checking, but we can drop that; as a result, we'll actually get more specific reporting about protocol breakage when packet_read dies internally. The only downside is that packet_read will not print the smart-http URL that failed, but that's not a big deal; anybody not debugging can already see the remote's URL already, and anybody debugging would want to run with GIT_CURL_VERBOSE anyway to see way more information. The second caller, which is just trying to skip past any extra smart-http headers (of which there are none defined, but which we allow to keep room for future expansion), did not error check at all. As a result, it would treat an error just like a flush packet. The resulting mess would generally cause an error later in get_remote_heads, but now we get error reporting much closer to the source of the problem. Brown-paper-bag-fixes-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
pkt-line: provide a LARGE_PACKET_MAX static buffer Most of the callers of packet_read_line just read into a static 1000-byte buffer (callers which handle arbitrary binary data already use LARGE_PACKET_MAX). This works fine in practice, because: 1. The only variable-sized data in these lines is a ref name, and refs tend to be a lot shorter than 1000 characters. 2. When sending ref lines, git-core always limits itself to 1000 byte packets. However, the only limit given in the protocol specification in Documentation/technical/protocol-common.txt is LARGE_PACKET_MAX; the 1000 byte limit is mentioned only in pack-protocol.txt, and then only describing what we write, not as a specific limit for readers. This patch lets us bump the 1000-byte limit to LARGE_PACKET_MAX. Even though git-core will never write a packet where this makes a difference, there are two good reasons to do this: 1. Other git implementations may have followed protocol-common.txt and used a larger maximum size. We don't bump into it in practice because it would involve very long ref names. 2. We may want to increase the 1000-byte limit one day. Since packets are transferred before any capabilities, it's difficult to do this in a backwards-compatible way. But if we bump the size of buffer the readers can handle, eventually older versions of git will be obsolete enough that we can justify bumping the writers, as well. We don't have plans to do this anytime soon, but there is no reason not to start the clock ticking now. Just bumping all of the reading bufs to LARGE_PACKET_MAX would waste memory. Instead, since most readers just read into a temporary buffer anyway, let's provide a single static buffer that all callers can use. We can further wrap this detail away by having the packet_read_line wrapper just use the buffer transparently and return a pointer to the static storage. That covers most of the cases, and the remaining ones already read into their own LARGE_PACKET_MAX buffers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221
  1. #ifndef PKTLINE_H
  2. #define PKTLINE_H
  3. #include "git-compat-util.h"
  4. #include "strbuf.h"
  5. #include "sideband.h"
  6. /*
  7. * Write a packetized stream, where each line is preceded by
  8. * its length (including the header) as a 4-byte hex number.
  9. * A length of 'zero' means end of stream (and a length of 1-3
  10. * would be an error).
  11. *
  12. * This is all pretty stupid, but we use this packetized line
  13. * format to make a streaming format possible without ever
  14. * over-running the read buffers. That way we'll never read
  15. * into what might be the pack data (which should go to another
  16. * process entirely).
  17. *
  18. * The writing side could use stdio, but since the reading
  19. * side can't, we stay with pure read/write interfaces.
  20. */
  21. void packet_flush(int fd);
  22. void packet_delim(int fd);
  23. void packet_write_fmt(int fd, const char *fmt, ...) __attribute__((format (printf, 2, 3)));
  24. void packet_buf_flush(struct strbuf *buf);
  25. void packet_buf_delim(struct strbuf *buf);
  26. void set_packet_header(char *buf, int size);
  27. void packet_write(int fd_out, const char *buf, size_t size);
  28. void packet_buf_write(struct strbuf *buf, const char *fmt, ...) __attribute__((format (printf, 2, 3)));
  29. void packet_buf_write_len(struct strbuf *buf, const char *data, size_t len);
  30. int packet_flush_gently(int fd);
  31. int packet_write_fmt_gently(int fd, const char *fmt, ...) __attribute__((format (printf, 2, 3)));
  32. int write_packetized_from_fd(int fd_in, int fd_out);
  33. int write_packetized_from_buf(const char *src_in, size_t len, int fd_out);
  34. /*
  35. * Read a packetized line into the buffer, which must be at least size bytes
  36. * long. The return value specifies the number of bytes read into the buffer.
  37. *
  38. * If src_buffer and *src_buffer are not NULL, it should point to a buffer
  39. * containing the packet data to parse, of at least *src_len bytes. After the
  40. * function returns, src_buf will be incremented and src_len decremented by the
  41. * number of bytes consumed.
  42. *
  43. * If src_buffer (or *src_buffer) is NULL, then data is read from the
  44. * descriptor "fd".
  45. *
  46. * If options does not contain PACKET_READ_GENTLE_ON_EOF, we will die under any
  47. * of the following conditions:
  48. *
  49. * 1. Read error from descriptor.
  50. *
  51. * 2. Protocol error from the remote (e.g., bogus length characters).
  52. *
  53. * 3. Receiving a packet larger than "size" bytes.
  54. *
  55. * 4. Truncated output from the remote (e.g., we expected a packet but got
  56. * EOF, or we got a partial packet followed by EOF).
  57. *
  58. * If options does contain PACKET_READ_GENTLE_ON_EOF, we will not die on
  59. * condition 4 (truncated input), but instead return -1. However, we will still
  60. * die for the other 3 conditions.
  61. *
  62. * If options contains PACKET_READ_CHOMP_NEWLINE, a trailing newline (if
  63. * present) is removed from the buffer before returning.
  64. *
  65. * If options contains PACKET_READ_DIE_ON_ERR_PACKET, it dies when it sees an
  66. * ERR packet.
  67. */
  68. #define PACKET_READ_GENTLE_ON_EOF (1u<<0)
  69. #define PACKET_READ_CHOMP_NEWLINE (1u<<1)
  70. #define PACKET_READ_DIE_ON_ERR_PACKET (1u<<2)
  71. int packet_read(int fd, char **src_buffer, size_t *src_len, char
  72. *buffer, unsigned size, int options);
  73. /*
  74. * Read a packetized line into a buffer like the 'packet_read()' function but
  75. * returns an 'enum packet_read_status' which indicates the status of the read.
  76. * The number of bytes read will be assigined to *pktlen if the status of the
  77. * read was 'PACKET_READ_NORMAL'.
  78. */
  79. enum packet_read_status {
  80. PACKET_READ_EOF,
  81. PACKET_READ_NORMAL,
  82. PACKET_READ_FLUSH,
  83. PACKET_READ_DELIM,
  84. };
  85. enum packet_read_status packet_read_with_status(int fd, char **src_buffer,
  86. size_t *src_len, char *buffer,
  87. unsigned size, int *pktlen,
  88. int options);
  89. /*
  90. * Convenience wrapper for packet_read that is not gentle, and sets the
  91. * CHOMP_NEWLINE option. The return value is NULL for a flush packet,
  92. * and otherwise points to a static buffer (that may be overwritten by
  93. * subsequent calls). If the size parameter is not NULL, the length of the
  94. * packet is written to it.
  95. */
  96. char *packet_read_line(int fd, int *size);
  97. /*
  98. * Convenience wrapper for packet_read that sets the PACKET_READ_GENTLE_ON_EOF
  99. * and CHOMP_NEWLINE options. The return value specifies the number of bytes
  100. * read into the buffer or -1 on truncated input. If the *dst_line parameter
  101. * is not NULL it will return NULL for a flush packet or when the number of
  102. * bytes copied is zero and otherwise points to a static buffer (that may be
  103. * overwritten by subsequent calls). If the size parameter is not NULL, the
  104. * length of the packet is written to it.
  105. */
  106. int packet_read_line_gently(int fd, int *size, char **dst_line);
  107. /*
  108. * Same as packet_read_line, but read from a buf rather than a descriptor;
  109. * see packet_read for details on how src_* is used.
  110. */
  111. char *packet_read_line_buf(char **src_buf, size_t *src_len, int *size);
  112. /*
  113. * Reads a stream of variable sized packets until a flush packet is detected.
  114. */
  115. ssize_t read_packetized_to_strbuf(int fd_in, struct strbuf *sb_out);
  116. /*
  117. * Receive multiplexed output stream over git native protocol.
  118. * in_stream is the input stream from the remote, which carries data
  119. * in pkt_line format with band designator. Demultiplex it into out
  120. * and err and return error appropriately. Band #1 carries the
  121. * primary payload. Things coming over band #2 is not necessarily
  122. * error; they are usually informative message on the standard error
  123. * stream, aka "verbose"). A message over band #3 is a signal that
  124. * the remote died unexpectedly. A flush() concludes the stream.
  125. *
  126. * Returns SIDEBAND_FLUSH upon a normal conclusion, and SIDEBAND_PROTOCOL_ERROR
  127. * or SIDEBAND_REMOTE_ERROR if an error occurred.
  128. */
  129. int recv_sideband(const char *me, int in_stream, int out);
  130. struct packet_reader {
  131. /* source file descriptor */
  132. int fd;
  133. /* source buffer and its size */
  134. char *src_buffer;
  135. size_t src_len;
  136. /* buffer that pkt-lines are read into and its size */
  137. char *buffer;
  138. unsigned buffer_size;
  139. /* options to be used during reads */
  140. int options;
  141. /* status of the last read */
  142. enum packet_read_status status;
  143. /* length of data read during the last read */
  144. int pktlen;
  145. /* the last line read */
  146. const char *line;
  147. /* indicates if a line has been peeked */
  148. int line_peeked;
  149. unsigned use_sideband : 1;
  150. const char *me;
  151. };
  152. /*
  153. * Initialize a 'struct packet_reader' object which is an
  154. * abstraction around the 'packet_read_with_status()' function.
  155. */
  156. void packet_reader_init(struct packet_reader *reader, int fd,
  157. char *src_buffer, size_t src_len,
  158. int options);
  159. /*
  160. * Perform a packet read and return the status of the read.
  161. * The values of 'pktlen' and 'line' are updated based on the status of the
  162. * read as follows:
  163. *
  164. * PACKET_READ_ERROR: 'pktlen' is set to '-1' and 'line' is set to NULL
  165. * PACKET_READ_NORMAL: 'pktlen' is set to the number of bytes read
  166. * 'line' is set to point at the read line
  167. * PACKET_READ_FLUSH: 'pktlen' is set to '0' and 'line' is set to NULL
  168. */
  169. enum packet_read_status packet_reader_read(struct packet_reader *reader);
  170. /*
  171. * Peek the next packet line without consuming it and return the status.
  172. * The next call to 'packet_reader_read()' will perform a read of the same line
  173. * that was peeked, consuming the line.
  174. *
  175. * Peeking multiple times without calling 'packet_reader_read()' will return
  176. * the same result.
  177. */
  178. enum packet_read_status packet_reader_peek(struct packet_reader *reader);
  179. #define DEFAULT_PACKET_MAX 1000
  180. #define LARGE_PACKET_MAX 65520
  181. #define LARGE_PACKET_DATA_MAX (LARGE_PACKET_MAX - 4)
  182. extern char packet_buffer[LARGE_PACKET_MAX];
  183. struct packet_writer {
  184. int dest_fd;
  185. unsigned use_sideband : 1;
  186. };
  187. void packet_writer_init(struct packet_writer *writer, int dest_fd);
  188. /* These functions die upon failure. */
  189. __attribute__((format (printf, 2, 3)))
  190. void packet_writer_write(struct packet_writer *writer, const char *fmt, ...);
  191. __attribute__((format (printf, 2, 3)))
  192. void packet_writer_error(struct packet_writer *writer, const char *fmt, ...);
  193. void packet_writer_delim(struct packet_writer *writer);
  194. void packet_writer_flush(struct packet_writer *writer);
  195. #endif