[PATCH 2/3] tests: Don't pass INT_MAX to virFileReadAll()

[Daniel P. Berrangé]

On Mon, Jun 14, 2021 at 02:26:48PM +0200, Peter Krempa wrote:
> On Mon, Jun 14, 2021 at 14:14:47 +0200, Michal Prívozník wrote:
> > On 6/14/21 1:31 PM, Tim Wiederhake wrote:
> > > On Mon, 2021-06-14 at 13:06 +0200, Michal Privoznik wrote:
> > >> In a few occasions in tests we pass INT_MAX to
> > >> virFileReadLimFD(). This is not safe because virFileReadAll()
> > >> will call virFileReadLimFD() under the hood which takes the limit
> > >> and adds 1 to it.
> > > 
> > > Calling virFileReadAll with "INT_MAX - 1" looks funny. Is it possible
> > > to check for "maxlen >= INT_MAX" in virFileReadLimFD instead?
> > 
> > Actually, I don't understand why we need to add 1 in the first place.
> > I'll push the other two patches and send v2 for this that removes the +1.
> 
> It's so that it guarantees that a file of 'maxlen' length is read
> completely and the terminating '\0' is in the resulting string.
> 
> Removing the '+ 1' would change this kind of semantics, which may
> require audit of all callers.

Isnt it just a matter of semantics of 'maxlen'. Your description is
saying the semantics for 'maxlen' are the total length of file plus
a possible trailing null.  Can we just define 'maxlen' to mean the
total length of the file, not including an extra trailing null ?

ie so that 'maxlen' is essentially equal to strlen(buf)  in the case
where the file has no embedded  nuls

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|