public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Sinz <msinz@wgate.com>
To: Alan Cox <alan@redhat.com>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] kernel 2.5.5 - coredump sysctl
Date: Thu, 21 Feb 2002 10:41:37 -0500	[thread overview]
Message-ID: <3C751531.AFFA30B1@wgate.com> (raw)
In-Reply-To: <200202211512.g1LFC8Y27614@devserv.devel.redhat.com>

Alan Cox wrote:
> 
> Would it be cleaner to use snprintf here ? Each of those checks you do
> appears to come down to
> 
>         buf+=snprintf(buf, sizeof(buffer)+buffer-buf, "%foo", arg)

	buf+=snprintf(buf, MAX_CORE_NAME - buf, "%foo", arg)

Hmm.... I was trying to keep things clear but if snprintf() is what
is prefered, it could be done so.  Most of the items here are just
string copies anyway, so the loop is trivial (and snprintf is
much higher overhead) 

snprintf is a bit more annoying due to the fact that snprintf returns
the number of bytes that *would have been written* and not the number
of bytes actually written if the limit is reached.  (Or, in older C
libraries, it returns -1 if the limit is hit)

(Don't complain to me that snprintf() is like that, it is C99 standard.
Older glibc have the -1 return code, which is also not really want
you want.)

BTW - I would really like to see this in the 2.4 kernels too - our
clusters really could use it (and do use it since I build the kernel
we use).

-- 
Michael Sinz -- msinz@wgate.com -- http://www.sinz.org
A master's secrets are only as good as
        the master's ability to explain them to others.

  reply	other threads:[~2002-02-21 15:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-21 14:33 [PATCH] kernel 2.5.5 - coredump sysctl Michael Sinz
2002-02-21 15:12 ` Alan Cox
2002-02-21 15:41   ` Michael Sinz [this message]
2002-02-21 15:50     ` Alan Cox
2002-02-27 13:33       ` Michael Sinz
2002-02-27 14:05         ` Alan Cox
2002-02-27 15:38           ` Michael Sinz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C751531.AFFA30B1@wgate.com \
    --to=msinz@wgate.com \
    --cc=alan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox