Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Evan Gates]

On Mon, Sep 5, 2016 at 12:41 AM, FRIGN  wrote:
> but this only happens if you typedef your structs, which I think is bad
> practice.
> If you do a
> #typedef struct hw homework
> this is your own fault. Using
> sizeof(struct hw)
> shows clearly it's a type, whereas
> sizeof(homework)
> is not clear. But this is more a criticism of extreme typedeffing. Stop
> using typedefs for structs and you won't have this problem any more. If
> you can't discern type names from variable names, this is your problem.

The style guide, which follows from "Unix Programming Environment,"
says to capitalize typedef names. In this way user defined types start
with a capital letter and all builtin types, variables, functions
start with a lower case letter.

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Evan Gates]

On Sun, Sep 4, 2016 at 11:35 PM, Anselm R Garbe  wrote:
> See http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf 6.5.3
> for unary operator specification of the C language.

6.5.3 shows (the relevant parts)
unary-expression:
postfix-expression

sizeof unary-expression
sizeof ( type-name )

6.5.2:
postfix-expression:
primary-expression


6.5.1:
primary-expression:

( expression )

As a result the parens are required for types, and acceptable for variables.

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Quentin Rameau]

> I think using goto loops sometimes is good, depend on the use case.
Obviously

> For example in spt.c:
> 
> run:
> notify_send(timers[i].cmt);
> 
> for (timecount = 0; timecount < timers[i].tmr; timecount +=
> inc) sleep(1);
> 
> if (++i >= LEN(timers)) i = 0; /* i infinal loop */
> goto run;
> 
> I tried using for and while loop, the goto loop still looks a lot
> better.

for (i = N; ; i = (i + 1) % LEN(timers)) {
for (timecount = 0; timecount < timers[i].tmr; timecount += inc)
sleep(1);
}

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Pickfire]

On Mon, Sep 05, 2016 at 09:55:49AM +0200, Anselm R Garbe wrote:

On 5 September 2016 at 09:52, FRIGN  wrote:

On Mon, 5 Sep 2016 09:48:34 +0200
Anselm R Garbe  wrote:
Using typedefs destroys this beautiful hierarchy.


Beware! There have been zealots arguing that using goto is a bad
practice for similar reasons.

typedef's have to be considered more carefully.


I think using goto loops sometimes is good, depend on the use case.

For example in spt.c:

run:
   notify_send(timers[i].cmt);

   for (timecount = 0; timecount < timers[i].tmr; timecount += inc)
   sleep(1);

   if (++i >= LEN(timers)) i = 0; /* i infinal loop */
   goto run;

I tried using for and while loop, the goto loop still looks a lot
better.
   


--
Do what you like, like what you do.  -- Pickfire

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Martin Kühne]

sizeof var (note the lack of parens) is a feature in c. It lets the
programmer put whatever type var is in one place and one place only.
The thing that got me away from putting parentheses to sizeof was
actually the fact that only in the absolutely rarest of cases (read:
never) you take the size of a thing that is not already in a scope
variable you're working on. If you get a type passed somewhere else,
have the size passed as a size_t argument and stick with that.

I started with C writing return() and sizeof() to have it all look the
same, but that has been brought to my attention to be ignorant
practise. Those are not in that sense functions, as one is an operator
and the other a control statement.

cheers!
mar77i

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[FRIGN]

On Mon, 5 Sep 2016 10:05:16 +0200
FRIGN  wrote:

> [...], but I respect the per-process style.

Of course I meant "per-project style".

-- 
FRIGN 

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[FRIGN]

On Mon, 5 Sep 2016 09:53:57 +0200
Anselm R Garbe  wrote:

Hey Anselm,

> That's wrong. There are good reasons like forward declarations /
> opaque type definitions that incorporate typedef.

how are you using the term forward declaration in this context? Are you
referring to function prototypes with "simpler" arguments?
As to opaque type definitions: There are very few cases where this
actually makes sense, especially in a language like C. Opaque types
often "present" themselves when developing toolboxes for numerical
issues, but often the incentives are not too high.

In dwm/dmenu the convention is to have the first type-letter uppercase,
like "Display". This is imho a good naming convention in itself and
does not require a new "format" for sizeof without parentheses if you
are so inclined to use typedefs for your structs.
I don't see a good reason to use typedefs in dwm/dmenu in the first
place, but I respect the per-process style.

Cheers

FRIGN

-- 
FRIGN 

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[FRIGN]

On Mon, 5 Sep 2016 09:55:49 +0200
Anselm R Garbe  wrote:

Hey Anselm,

> Beware! There have been zealots arguing that using goto is a bad
> practice for similar reasons.
> 
> typedef's have to be considered more carefully.

zealots argue against goto because it's a low-level feature and they
have not understood that loops are basically using goto under the hood.
So we can identify the notion against goto as the fear of low-level
stuff and a fear of low-abstraction.

With typedefs, we are going another direction, because typedefs are a
"high-abstraction" just like using 

if () {

} else if () {
if () {

} else {

}
}

trees just not to have gotos in the code.

Cheers

FRIGN

-- 
FRIGN 

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Anselm R Garbe]

On 5 September 2016 at 09:50, FRIGN  wrote:
> On Mon, 5 Sep 2016 09:42:47 +0200
> Anselm R Garbe  wrote:
>> Why is typedef'ing structs bad practice?
>
> because there's no reason for it other than syntax candy. It also hides

That's wrong. There are good reasons like forward declarations /
opaque type definitions that incorporate typedef.

> from the user what he is dealing with and when I want to lookup a
> struct definition I often have to jungle-jump across multiple typedef
> layers to finally reach the definition.

Of course typedef's can over-complicate code, but they can also
simplify code. I'm referring to the latter.

One can find good and bad examples, imho dwm/dmenu are good examples
of typedef usage. I'm just referring to those.

Granted, Xlib is more of the sort bad example.

Cheers,
Anselm

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[FRIGN]

On Mon, 5 Sep 2016 09:42:47 +0200
Anselm R Garbe  wrote:

Hey Anselm,

> Why is typedef'ing structs bad practice?

because there's no reason for it other than syntax candy. It also hides
from the user what he is dealing with and when I want to lookup a
struct definition I often have to jungle-jump across multiple typedef
layers to finally reach the definition.

If I have a program for handling bank accounts and define an
account-struct like

struct account {
char *firstname;
char *lastname;
int balance;
};

I think it's more descriptive in the code to declare a local variable
like

struct account fisher;

rather than having a typdef

#typedef struct account Account

which yields

Account fisher;

It may look "nicer", "cleaner", "shorter", but it just hides
information from the user. Look at the Posix socket interfaces; there's
a reason why all the sock-address structs were left as-is and why a
messy project like X11 typedefs the shit out of its structs. The
ultimate reason is because X11 has become so complex that its authors
tried to at least make it visually half-appealing by "shortening" their
code with struct typedefs. If your code has become so complex and
overwhelming that plain "struct structname" constructs can't be fitted
in there any more you should fix it. That's my opinion.

Cheers

FRIGN

-- 
FRIGN 

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Anselm R Garbe]

On 5 September 2016 at 09:44, FRIGN  wrote:
> On Mon, 5 Sep 2016 09:39:24 +0200
> Anselm R Garbe  wrote:
>> I'm referring to NOT using parentheses to make it explicitely clear,
>> that the expression is not referring to a type. See sec. 6.5.3 in the
>> C lang spec for further details.
>
> why would there ever be a doubt that "unsigned char" is a type? Even if
> you use the stdint.h types, e.g. uint8_t, Posix has noticed and taken
> measures to make it clear with the _t suffix that uint8_t is a type.

Haha, you now open up another bad thing imho. I tried to avoid
_t-suffix crap in all my code so far.

Cheers,
Anselm

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[FRIGN]

On Mon, 5 Sep 2016 09:39:24 +0200
Anselm R Garbe  wrote:

Hey Anselm,

> Why should I try. This is blatantly obvious wrong code.
> 
> I'm referring to NOT using parentheses to make it explicitely clear,
> that the expression is not referring to a type. See sec. 6.5.3 in the
> C lang spec for further details.

why would there ever be a doubt that "unsigned char" is a type? Even if
you use the stdint.h types, e.g. uint8_t, Posix has noticed and taken
measures to make it clear with the _t suffix that uint8_t is a type.

As I mentioned earlier, if you cannot discern a type name from a
variable name it's your problem and should not be "fixed" by having a
strange use of sizeof which is error-prone, as Ali has well shown.
This obviously goes the other way around too. One should not use
variable names that can be misinterpreted as a typename.

Cheers

FRIGN

-- 
FRIGN 

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Anselm R Garbe]

On 5 September 2016 at 09:41, FRIGN  wrote:
> On Mon, 5 Sep 2016 09:37:17 +0200
> Anselm R Garbe  wrote:
>> I disagree. Not using parentheses as sizeof arguments makes it pretty
>> clear, that the expression is *not* about the size of a type, but
>> rather needs to be evaluated. In dwm/dmenu code this has been
>> respected until now for a very long time. I would keep this principle
>> in place for other suckless tools as well.
>
> but this only happens if you typedef your structs, which I think is bad
> practice.

Why is typedef'ing structs bad practice?

-Anselm

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Ali H. Fardan]

On 2016-09-05 10:39, Anselm R Garbe wrote:

Why should I try. This is blatantly obvious wrong code.


and that's my point.

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[FRIGN]

On Mon, 5 Sep 2016 09:37:17 +0200
Anselm R Garbe  wrote:

Hey Anselm,

> I disagree. Not using parentheses as sizeof arguments makes it pretty
> clear, that the expression is *not* about the size of a type, but
> rather needs to be evaluated. In dwm/dmenu code this has been
> respected until now for a very long time. I would keep this principle
> in place for other suckless tools as well.

but this only happens if you typedef your structs, which I think is bad
practice.
If you do a
#typedef struct hw homework
this is your own fault. Using
sizeof(struct hw)
shows clearly it's a type, whereas
sizeof(homework)
is not clear. But this is more a criticism of extreme typedeffing. Stop
using typedefs for structs and you won't have this problem any more. If
you can't discern type names from variable names, this is your problem.

Cheers

FRIGN

-- 
FRIGN 

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Anselm R Garbe]

On 5 September 2016 at 09:25, FRIGN  wrote:
> On Mon, 5 Sep 2016 07:42:36 +0200
> Anselm R Garbe  wrote:
>> Quick note: your syntax usage of sizeof is not 100% accurate.
>>
>> Use 'sizeof(type)' with brackets but 'sizeof var' without.
>
> I use sizeof always function-like and see no reason why I shouldn't use
> "sizeof(var)" and instead use "sizeof var". It doesn't alter the code
> behaviour and ultimately it's all about readability.
> If you eyes have become accustomed to always use function-like syntax
> for such operators the best bet is not to break this style because it's
> not "necessary" to have parentheses for variable sizeof's.

I disagree. Not using parentheses as sizeof arguments makes it pretty
clear, that the expression is *not* about the size of a type, but
rather needs to be evaluated. In dwm/dmenu code this has been
respected until now for a very long time. I would keep this principle
in place for other suckless tools as well.

Cheers,
Anselm

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Ali H. Fardan]

I got an example:
try compiling this code:

#include 

int
main(void)
{
printf("%d", sizeof unsigned char);
return (0);
}

you will probably get a compiler error like this:

sizeof.c: In function ‘main’:
sizeof.c:6:22: error: expected expression before ‘unsigned’
  printf("%d", sizeof unsigned char);
  ^~~~
However, with parenthesies:

#include 

int
main(void)
{
printf("%d\n", sizeof(unsigned char));
return (0);
}

It will compile successfully.

Hope you got the idea

Raiz

On 2016-09-05 10:25, FRIGN wrote:

On Mon, 5 Sep 2016 07:42:36 +0200
Anselm R Garbe  wrote:

Hey Anselm,


Quick note: your syntax usage of sizeof is not 100% accurate.

Use 'sizeof(type)' with brackets but 'sizeof var' without.


I use sizeof always function-like and see no reason why I shouldn't use
"sizeof(var)" and instead use "sizeof var". It doesn't alter the code
behaviour and ultimately it's all about readability.
If you eyes have become accustomed to always use function-like syntax
for such operators the best bet is not to break this style because it's
not "necessary" to have parentheses for variable sizeof's.

Cheers

FRIGN

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[FRIGN]

On Mon, 5 Sep 2016 07:42:36 +0200
Anselm R Garbe  wrote:

Hey Anselm,

> Quick note: your syntax usage of sizeof is not 100% accurate.
> 
> Use 'sizeof(type)' with brackets but 'sizeof var' without.

I use sizeof always function-like and see no reason why I shouldn't use
"sizeof(var)" and instead use "sizeof var". It doesn't alter the code
behaviour and ultimately it's all about readability.
If you eyes have become accustomed to always use function-like syntax
for such operators the best bet is not to break this style because it's
not "necessary" to have parentheses for variable sizeof's.

Cheers

FRIGN

-- 
FRIGN 

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Ali H. Fardan]

On 2016-09-05 08:53, Markus Teich wrote:
can you elaborate on the reasoning behind this? The styleguide says 
"Always use

() with sizeof".


from my experience, using sizeof without parenthesies could cause
errors.

Raiz

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Anselm R Garbe]

On 5 September 2016 at 07:53, Markus Teich  wrote:
> Anselm R Garbe wrote:
>> Use 'sizeof(type)' with brackets but 'sizeof var' without.
>
> Heyho Anselm,
>
> can you elaborate on the reasoning behind this? The styleguide says "Always 
> use
> () with sizeof".

The styleguide needs to be fixed.

See http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf 6.5.3
for unary operator specification of the C language.

-Anselm

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Markus Teich]

Anselm R Garbe wrote:
> Use 'sizeof(type)' with brackets but 'sizeof var' without.

Heyho Anselm,

can you elaborate on the reasoning behind this? The styleguide says "Always use
() with sizeof".

--Markus

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[Anselm R Garbe]

Quick note: your syntax usage of sizeof is not 100% accurate.

Use 'sizeof(type)' with brackets but 'sizeof var' without.

BR,
Anselm


On 5 September 2016 at 00:08,   wrote:
> commit 5ecd11fa3d42d7d474bf08c00e074eac52124d8f
> Author: FRIGN 
> AuthorDate: Mon Sep 5 00:08:25 2016 +0200
> Commit: FRIGN 
> CommitDate: Mon Sep 5 00:08:25 2016 +0200
>
> Use sizeof() instead of magic constants
>
> diff --git a/quark.c b/quark.c
> index b42bba6..2c03271 100644
> --- a/quark.c
> +++ b/quark.c
> @@ -56,7 +56,6 @@ static char *statistr[] = {
> [S_REQUEST_TOO_LARGE] = "Request Header Fields Too Large",
> [S_INTERNAL_SERVER_ERROR] = "Internal Server Error",
> [S_VERSION_NOT_SUPPORTED] = "HTTP Version not supported",
> -
>  };
>
>  #undef MIN
> @@ -83,52 +82,52 @@ sendstatus(enum stati code, int fd, ...)
> ssize_t ret;
> long lower, upper, size;
>
> -   buflen = snprintf(buf, 4096, "HTTP/1.1 %d %s\r\n", code,
> +   buflen = snprintf(buf, sizeof(buf), "HTTP/1.1 %d %s\r\n", code,
>   statistr[code]);
>
> -   buflen += snprintf(buf + buflen, 4096 - buflen, "Date: %s\r\n",
> -  timestamp(0));
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
> +  "Date: %s\r\n", timestamp(0));
> va_start(ap, fd);
> switch (code) {
> case S_OK: /* arg-list: mime, size */
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Content-Type: %s\r\n",
>va_arg(ap, char *));
> if ((size = va_arg(ap, long)) >= 0) {
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Content-Length: %ld\r\n",
>size);
> }
> break;
> case S_PARTIAL_CONTENT: /* arg-list: mime, lower, upper, size */
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Content-Type: %s\r\n",
>va_arg(ap, char *));
> lower = va_arg(ap, long);
> upper = va_arg(ap, long);
> size = va_arg(ap, long);
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Content-Range: bytes %ld-%ld/%ld\r\n",
>lower, upper, size);
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Content-Length: %ld\r\n",
>(upper - lower) + 1);
> break;
> case S_MOVED_PERMANENTLY: /* arg-list: host, url */
> if (!strcmp(port, "80")) {
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Location: http://%s%s\r\n;,
>va_arg(ap, char *),
>va_arg(ap, char *));
> } else {
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Location: http://%s:%s%s\r\n;,
>va_arg(ap, char *), port,
>va_arg(ap, char *));
> }
> break;
> case S_METHOD_NOT_ALLOWED: /* arg-list: none */
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Allow: GET\r\n");
> break;
> default:
> @@ -136,20 +135,20 @@ sendstatus(enum stati code, int fd, ...)
> }
> va_end(ap);
>
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Connection: close\r\n");
>
> if (code != S_OK && code != S_PARTIAL_CONTENT) {
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
>"Content-Type: text/html\r\n");
> -   buflen += snprintf(buf + buflen, 4096 - buflen,
> +   buflen += 

[hackers] [quark] Use sizeof() instead of magic constants || FRIGN

[git]

commit 5ecd11fa3d42d7d474bf08c00e074eac52124d8f
Author: FRIGN 
AuthorDate: Mon Sep 5 00:08:25 2016 +0200
Commit: FRIGN 
CommitDate: Mon Sep 5 00:08:25 2016 +0200

Use sizeof() instead of magic constants

diff --git a/quark.c b/quark.c
index b42bba6..2c03271 100644
--- a/quark.c
+++ b/quark.c
@@ -56,7 +56,6 @@ static char *statistr[] = {
[S_REQUEST_TOO_LARGE] = "Request Header Fields Too Large",
[S_INTERNAL_SERVER_ERROR] = "Internal Server Error",
[S_VERSION_NOT_SUPPORTED] = "HTTP Version not supported",
-
 };
 
 #undef MIN
@@ -83,52 +82,52 @@ sendstatus(enum stati code, int fd, ...)
ssize_t ret;
long lower, upper, size;
 
-   buflen = snprintf(buf, 4096, "HTTP/1.1 %d %s\r\n", code,
+   buflen = snprintf(buf, sizeof(buf), "HTTP/1.1 %d %s\r\n", code,
  statistr[code]);
 
-   buflen += snprintf(buf + buflen, 4096 - buflen, "Date: %s\r\n",
-  timestamp(0));
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
+  "Date: %s\r\n", timestamp(0));
va_start(ap, fd);
switch (code) {
case S_OK: /* arg-list: mime, size */
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Content-Type: %s\r\n",
   va_arg(ap, char *));
if ((size = va_arg(ap, long)) >= 0) {
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Content-Length: %ld\r\n",
   size);
}
break;
case S_PARTIAL_CONTENT: /* arg-list: mime, lower, upper, size */
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Content-Type: %s\r\n",
   va_arg(ap, char *));
lower = va_arg(ap, long);
upper = va_arg(ap, long);
size = va_arg(ap, long);
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Content-Range: bytes %ld-%ld/%ld\r\n",
   lower, upper, size);
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Content-Length: %ld\r\n",
   (upper - lower) + 1);
break;
case S_MOVED_PERMANENTLY: /* arg-list: host, url */
if (!strcmp(port, "80")) {
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Location: http://%s%s\r\n;,
   va_arg(ap, char *),
   va_arg(ap, char *));
} else {
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Location: http://%s:%s%s\r\n;,
   va_arg(ap, char *), port,
   va_arg(ap, char *));
}
break;
case S_METHOD_NOT_ALLOWED: /* arg-list: none */
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Allow: GET\r\n");
break;
default:
@@ -136,20 +135,20 @@ sendstatus(enum stati code, int fd, ...)
}
va_end(ap);
 
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Connection: close\r\n");
 
if (code != S_OK && code != S_PARTIAL_CONTENT) {
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "Content-Type: text/html\r\n");
-   buflen += snprintf(buf + buflen, 4096 - buflen,
+   buflen += snprintf(buf + buflen, sizeof(buf) - buflen,
   "\r\n\r\n\r\n"
   "\t%d %s"
   "\r\n\t%d %s\r\n"
   "\r\n", code, statistr[code],
   code, statistr[code]);
} else {
-   buflen += snprintf(buf + buflen,