[PATCH 07/10] command: Replace incorrect use of LENGTH().

Simon Ruderich simon at ruderich.org
Wed Feb 5 14:51:30 CET 2014

On Tue, Feb 04, 2014 at 01:52:30PM +0100, Thorsten Wißmann wrote:
> On Sat, Feb 01, 2014 at 09:56:42PM +0100, Simon Ruderich wrote:
>> LENGTH() has no negative effects because sizeof(char) == 1, but sizeof()
>> makes the intention clear.
>> -    snprintf(buf, LENGTH(buf), "0x%lx", client->window);
>> +    snprintf(buf, sizeof(buf), "0x%lx", client->window);
> I mean both is right, but the question is what this parameter means.

snprintf() takes the length of the buffer in bytes as second
argument, not the number of elements. Of course in this case it's
the same, but why introduce a level of indirection here? sizeof()
is what everybody expects.

> E.g. in wchar versions it seems this is the length of the buffer and not
> the total size in bytes of the underlying data structure, of course they
> coincide in the case of ordinary chars.

> I personally find LENGTH more readable because it is really the length
> of the array, while sizeof gives it's total size.

Exactly, which is what snprintf() takes as argument. The length
of the array in bytes, which is not always the same as LENGTH().

> So I would not agree that sizeof makes the intention clear.

It's not a big issue, I just noticed it and it didn't seem clear
to be because of the element vs. byte count difference so I
changed it.

+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20140205/da73449d/attachment.asc>

More information about the hlwm mailing list