On Tue, 2019-10-22 at 09:47 -0700, Bart Van Assche wrote: > On 2019-10-22 09:07, Martin Wilck wrote: > > > > In this particular case, we're dealing with a historically-caused > > property of snprintf(), as you are probably aware > > ( > > https://stackoverflow.com/questions/45740276/why-does-printf-return-an-int-instead-of-a-size-t-in-c > > ), > > so I'd argue the ugliness is forced upon us, sort of. > > > > We can hide the ugliness in a macro if you prefer. Actually, we > > have > > safe_snprintf() already. We just need to use it in all places where > > this kind of comparison is made. Would that be acceptable to you? > > Hi Martin, > > Have you considered to use asprintf() instead of snprintf() and a > check > whether the output buffer overflows? I think the former is a more > elegant solution. Most uses of snprintf() are in libmultipath printing code, where items are printed sequentially into a big buffer, advancing the buffer pointer on the way. asprintf() doesn't match that use case well, AFAICS. But in some other places, switching to asprintf would certainly make sense. Anyway, I'd like to do that in a separate patch set if you don't mind; this one is big enough already. Thanks, Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
