The `RECTANGLE` PDU is pretty common, so it's good to have a helper for
writing this, so it doesn't need to be open-coded everywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This is writing the contents of source rpcbuf into the target one,
pads it and finally clears the source buffer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a helper for writing pascal-type strings: the counter is written
as CARD16, then followed by the string characters (w/o zero), and
finally everything padded up to full protocol units.
This encoding is used in various places throughout the Xserver,
eg. in xkb.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Just a convenience wrapper for writing an INT16.
Technically it's really the same as CARD16, but we still need a typecast
in order to not getting a compiler warning on int signedness mismatch.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
New function for padding the buffer to full protocol units granularity:
If the current write position isn't at 4-byte granularity, it reserves
the remaining number of bytes (ie. writing zeros), in order to make the
next write align to 4-byte granularity again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Practically all callers need to assign to a CARD32 field, so let it
directly compute and return as CARD32.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of always zero'ing out the whole buffer at allocation time, only
do it where really necessary. Also adding x_rpcbuf_reserve0() for reserving
buffer space that's explicitly cleared.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both are the same types, the `struct x_rpcbuf` still remains, but it
seems more clear to use the `x_rpcbuf_t` as the canonical name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
add x_rpcbuf_wsize_units() to retrieve the amount of data written into
the buffer - in 4-byte units.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The existing x_rpcbuf_write_string() function is just writing the string w/o
trailing zero. It's for cases where the string length is known by other means
(eg. some header field). In cases where we also need the trailing zero written
(eg. when sending lists of strings) this isn't sufficient.
Thus introducing another variant of this function, which is always writing
a leading zero. Using this one, the string's characters will be followed
by 1, 2 or 3 zeros (and also be 32bit aligned)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
when the err_clear flag is set, the buffer memory will automatically
be free()ed when allocation failed. This allows simplificatoin of
caller's error pathes: the caller doesn't need to to call x_rpcbuf_clear()
anymore and eg. can directly return out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Remember allocation failure in new `error` field, for easing error
handling in complex callers: those now don't need to check each single
return value, but can (try to) continue their normal operation and
check for error condition later.
For example we can turn this:
for (....) {
if (!x_rpcbuf_write_CARD16(&rpcbuf,...)) {
[ various cleanups ]
return BadAlloc;
}
if (!rpcbuf_write_CARD8s(&rpcbuf,...)) {
[ various cleanups ]
return BadAlloc;
}
[ more of this ]
}
...
Into:
for (....) {
x_rpcbuf_write_CARD16(&rpcbuf,...));
x_rpcbuf_write_CARD8s(&rpcbuf,...));
[ more of this ]
}
...
if (&rpcbuf->error) {
[ various cleanups ]
return BadAlloc;
}
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since so many request handlers have to assemble complex reply payloads,
we've got a lot complexity on counting the needed space and filling in
the data into the right places.
Thus adding a little dynamic buffer structure, where one just can append
data arbitrarily. The buffer will automatically allocate memory as-needed
and finally leave everything in a big memory block for later write-out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
