A small patch from my wanderings today for your review. This patch to
kvprintf() allows me to set a %b format string of:
\20\0unset\1ONESET\2TWOSET
In the case that the variable being compared has the value of 0, it will
display 0x0unset
http://people.freebsd.org/~sbruno/subr_prf.txt
Sean
On Tue Dec 6 11, David Schultz wrote:
On Sun, Dec 04, 2011, Alexander Best wrote:
... i couldn't find a reference to an upercase Z in the printf(9) man
page.
i talked to dinoex on #freebsd-clang (EFNet) and he said that the Z might
come from linux'es libc5 and is the equaivalent
Am 16.12.2011 12:27, schrieb Alexander Best:
On Tue Dec 6 11, David Schultz wrote:
On Sun, Dec 04, 2011, Alexander Best wrote:
... i couldn't find a reference to an upercase Z in the printf(9) man
page.
i talked to dinoex on #freebsd-clang (EFNet) and he said that the Z might
come from
On Sun, Dec 04, 2011, Alexander Best wrote:
... i couldn't find a reference to an upercase Z in the printf(9) man page.
i talked to dinoex on #freebsd-clang (EFNet) and he said that the Z might
come from linux'es libc5 and is the equaivalent to glibc's z.
can we adjust those lines, so
On Tue Dec 6 11, David Schultz wrote:
On Sun, Dec 04, 2011, Alexander Best wrote:
... i couldn't find a reference to an upercase Z in the printf(9) man
page.
i talked to dinoex on #freebsd-clang (EFNet) and he said that the Z might
come from linux'es libc5 and is the equaivalent
: expanded from:
#define DRM_INFO(fmt, ...) printf(info: [ DRM_NAME ] fmt ,
##__VA_ARGS__)
^
these lines should cover all warnings:
otaku% egrep -r %[0-9]*Zx /usr/src/sys/dev/drm
dev/drm/mga_drv.h: DRM_INFO( space=0x%x
, \
^
@/dev/drm/drmP.h:317:60: note: expanded from:
#define DRM_INFO(fmt, ...) printf(info: [ DRM_NAME ] fmt ,
##__VA_ARGS__)
^
these lines should cover all warnings:
otaku% egrep -r %[0-9]*Zx /usr/src/sys
, \
^
@/dev/drm/drmP.h:317:60: note: expanded from:
#define DRM_INFO(fmt, ...) printf(info: [ DRM_NAME ] fmt ,
##__VA_ARGS__)
^
these lines should cover all warnings
);
^~~
@/dev/drm/mga_drv.h:291:35: note: expanded from:
DRM_INFO(space=0x%x req=0x%Zx\n, \
^
@/dev/drm/drmP.h:317:60: note: expanded from:
#define DRM_INFO(fmt, ...) printf(info: [ DRM_NAME ] fmt
On 6/7/11 6:33 PM, Dieter BSD wrote:
I've been working on fixing problems with printf(9), log(9) and
related functions. Today I tried converting printf(9) to write
to the log rather than directly to the console, unless the log is
not open, in which case the message is also sent
I've been working on fixing problems with printf(9), log(9) and
related functions. Today I tried converting printf(9) to write
to the log rather than directly to the console, unless the log is
not open, in which case the message is also sent to the console.
Printf(...) is now the same as log
On 6/7/11 12:57 PM, Dieter BSD wrote:
I've been working on fixing problems with printf(9), log(9) and
related functions. Today I tried converting printf(9) to write
to the log rather than directly to the console, unless the log is
not open, in which case the message is also sent to the console
I've been working on fixing problems with printf(9), log(9) and
related functions. Today I tried converting printf(9) to write
to the log rather than directly to the console, unless the log is
not open, in which case the message is also sent to the console.
Printf(...) is now the same as log
On 6/7/11 6:33 PM, Dieter BSD wrote:
I've been working on fixing problems with printf(9), log(9) and
related functions. Today I tried converting printf(9) to write
to the log rather than directly to the console, unless the log is
not open, in which case the message is also sent to the console
So, for example int64_t has no printf modifier I am aware of. Likewise
its many friends.
In the past I've handled this by having a define somewhere along the
lines of...
#if something
# define INT_64_T_FMT %ld
#else
# define INT_64_T_FMT %lld
#endif
but I have no idea where to put such a thing
On Sun, 5 Jun 2011, Ben Laurie wrote:
So, for example int64_t has no printf modifier I am aware of. Likewise
its many friends.
In the past I've handled this by having a define somewhere along the
lines of...
#if something
# define INT_64_T_FMT %ld
#else
# define INT_64_T_FMT %lld
#endif
On Sun, Jun 5, 2011 at 11:13 AM, Ben Laurie b...@links.org wrote:
So, for example int64_t has no printf modifier I am aware of. Likewise
its many friends.
The worse option is to use the C99 defines, like PRI64 and PRI64U.
The better option is to use %jd / %ju and cast the value to
[u]intmax_t
On Sun, Jun 05, 2011 at 02:31:27PM -0400, Sean C. Farley wrote:
On Sun, 5 Jun 2011, Ben Laurie wrote:
So, for example int64_t has no printf modifier I am aware of. Likewise
its many friends.
In the past I've handled this by having a define somewhere along the
lines
In message 4debc741.1020...@links.org, Ben Laurie writes:
So, for example int64_t has no printf modifier I am aware of. Likewise
its many friends.
but I have no idea where to put such a thing in FreeBSD. Opinions?
I have totally given up on this mess.
At best you get incredibly messy source
On 05/06/2011 19:21, Poul-Henning Kamp wrote:
In message 4debc741.1020...@links.org, Ben Laurie writes:
So, for example int64_t has no printf modifier I am aware of. Likewise
its many friends.
but I have no idea where to put such a thing in FreeBSD. Opinions?
I have totally given up
On 05/06/2011 19:31, Sean C. Farley wrote:
On Sun, 5 Jun 2011, Ben Laurie wrote:
So, for example int64_t has no printf modifier I am aware of. Likewise
its many friends.
In the past I've handled this by having a define somewhere along the
lines of...
#if something
# define INT_64_T_FMT
In message 4debe469.5060...@links.org, Ben Laurie writes:
On 05/06/2011 19:21, Poul-Henning Kamp wrote:
In message 4debc741.1020...@links.org, Ben Laurie writes:
I have therefore resorted to printf'ing any typedefed integer type using
%jd and an explicit cast to (intmax_t):
printf
and an explicit cast to (intmax_t):
printf(%-30s - %jd - %s\n, s, (intmax_t)t, buf);
My objection to this approach is the lack of type-safety - t could be
anything and this would continue to work.
Using PRId64 at least ensures that t is of an appropriate type.
Uhm, no, it doesn't.
At best
In message 4debf0e7.3040...@links.org, Ben Laurie writes:
I note that you didn't react to my other wherein you cast from known
type A to known type B. I supposed it would be smart to also assert that
the cast was non-narrowing.
Well, if casting to intmax_t is narrowing I think I have bigger
While working on other problems with *printf(9), log(9), etc.
I stumbled upon:
options PRINTF_BUFR_SIZE=128# Prevent printf output being
interspersed.
Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is supposed
to prevent this:
ada2: 300.000MB/s transfuhub2: 3 ports with 3
On Sat Apr 9 11, dieter...@engineer.com wrote:
While working on other problems with *printf(9), log(9), etc.
I stumbled upon:
options PRINTF_BUFR_SIZE=128# Prevent printf output being
interspersed.
Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is supposed
to prevent
While working on other problems with *printf(9), log(9), etc.
I stumbled upon:
options PRINTF_BUFR_SIZE=128 # Prevent printf output being
interspersed.
Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is
supposed
to prevent this:
ada2: 300.000MB/s transfuhub2: 3 ports with 3
Robert writes:
Why would doing a printf(9) in a device driver (usb, firewire,
probably
others) cause an obscenely long lockout on
/usr/src/sys/kern/uipc_sockbuf.c:148 (sx:so_rcv_sx) ?
Printf(9) alone isn't the problem, adding printfs to chown(2) does
not
cause the problem, but printfs
I received a suggestion to try witness, so I build a kernel with
WITNESS, WITNESS_KDB, KDB, DDB, KDB_TRACE, and DDB_NUMSYM.
This is my first attempt to use witness, so if I got something wrong
let me know. Didn't quite make it all the way up to a multiuser prompt:
Starting syslogd.
Starting
Why would doing a printf(9) in a device driver (usb, firewire, probably
others) cause an obscenely long lockout on
/usr/src/sys/kern/uipc_sockbuf.c:148 (sx:so_rcv_sx) ?
Printf(9) alone isn't the problem, adding printfs to chown(2) does not
cause the problem, but printfs from device drivers do
On Sat, 5 Feb 2011, dieter...@engineer.com wrote:
Why would doing a printf(9) in a device driver (usb, firewire, probably
others) cause an obscenely long lockout on
/usr/src/sys/kern/uipc_sockbuf.c:148 (sx:so_rcv_sx) ?
Printf(9) alone isn't the problem, adding printfs to chown(2) does
on 22/11/2010 01:18 Paul B Mahol said the following:
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon a...@freebsd.org wrote:
As is - this is a perfect candidate for a local only patch.
To be included into the tree - this, most probably, has to be controlled by a
tunable/sysctl.
So solution
On Sun, Nov 21, 2010 at 10:18:13PM -0200, Carlos A. M. dos Santos wrote:
On Sun, Nov 21, 2010 at 9:18 PM, Paul B Mahol one...@gmail.com wrote:
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon a...@freebsd.org wrote:
on 21/11/2010 13:07 Paul B Mahol said the following:
This patch removes printf
On 11/22/10, Andriy Gapon a...@freebsd.org wrote:
on 22/11/2010 01:18 Paul B Mahol said the following:
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon a...@freebsd.org wrote:
As is - this is a perfect candidate for a local only patch.
To be included into the tree - this, most probably, has to be
Hello Hackers,
Recently I installed 8.1 on my laptop and recompiled the kernel.
The system works fine, but I have a strange problem with my own
trivial kernel module.
I noticed that printf function doesn't produce any output (according to
dmesg) if I call it from a module. Note, that the same
On Mon, Nov 22, 2010 at 5:38 AM, Dmitry Krivenok
krivenok.dmi...@gmail.com wrote:
Hello Hackers,
Recently I installed 8.1 on my laptop and recompiled the kernel.
The system works fine, but I have a strange problem with my own
trivial kernel module.
I noticed that printf function doesn't
Just tried dys_sysctl. It doesn't work as well.
Below are the results I got:
r...@olimpico-freebsd 22:04:17 /usr/share/examples/kld/dyn_sysctl # [0] uname -a
FreeBSD olimpico-freebsd 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Nov
22 21:35:15 MSK 2010
This patch removes printf which spams console whenever thermal state
is changed in laptop. Source of problem is in buggy BIOS.
diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
index 515a742..00866b2 100644
--- a/sys/dev/acpica/acpi_thermal.c
+++ b/sys/dev/acpica
on 21/11/2010 13:07 Paul B Mahol said the following:
This patch removes printf which spams console whenever thermal state
is changed in laptop. Source of problem is in buggy BIOS.
diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
index 515a742..00866b2 100644
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon a...@freebsd.org wrote:
on 21/11/2010 13:07 Paul B Mahol said the following:
This patch removes printf which spams console whenever thermal state
is changed in laptop. Source of problem is in buggy BIOS.
diff --git a/sys/dev/acpica/acpi_thermal.c
On Sun, Nov 21, 2010 at 9:18 PM, Paul B Mahol one...@gmail.com wrote:
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon a...@freebsd.org wrote:
on 21/11/2010 13:07 Paul B Mahol said the following:
This patch removes printf which spams console whenever thermal state
is changed in laptop. Source
Hi,
I'm trying to correct some warnings in a port marked
ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume
is a 64-bit unsigned) to unsigned int which is apparently 32 bits?
I sort of thought int was supposed to be the atomic register size, but
no doubt that would break more
On Thu, Sep 18, 2008 at 10:41:42AM -0700, Steve Franks wrote:
I'm trying to correct some warnings in a port marked
ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume
is a 64-bit unsigned) to unsigned int which is apparently 32 bits?
I sort of thought int was supposed to be
is actually being printed isn't a pointer, but the difference
between two pointers (I assume from your comments; the code included
isn't enough to show where they come from). That means the correct
type of what's being printed is size_t, which our printf seems to
support with a z modifier. Removing
On Thursday 18 September 2008 01:41:42 pm Steve Franks wrote:
Hi,
I'm trying to correct some warnings in a port marked
ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume
is a 64-bit unsigned) to unsigned int which is apparently 32 bits?
I sort of thought int was supposed
of what's being printed is size_t, which our printf seems to
support with a z modifier. Removing the explicit casts or (if
necessary), replacing them with something that is big enough will also
be needed.
The difference of two pointers is actually a ptrdiff_t rather than a size_t.
size_t is what
Pretty late to the game, but ...
On Mon, 08.09.2008 at 15:47:20 +0200, Oliver Fromme wrote:
Jeremy Chadwick wrote:
Equally as frustrating, mutt's backtick support will only honour the
first line of input. If a backticked command returns multiple lines,
only the first is read; the rest are
on the fly below:
http://wiki.mutt.org/?ConfigTricks
Note the find ... -printf '%h ' method. I can accomplish (just
about) the same using `echo $HOME/Maildir/*`, but if I want to
exclude an entry, I can't use | grep -v, because mutt doesn't support
pipes within backticks
), and
some escaped characters.
Things I need help with, as string parsing in C has never been my forte
(which will become quite obvious):
1) Getting %h to behave like GNU find. The GNU find code is
significantly different than ours. As it stands, %h is broken.
2) find . -printf '\' results
://wiki.mutt.org/?ConfigTricks
Note the find ... -printf '%h ' method. I can accomplish (just
about) the same using `echo $HOME/Maildir/*`, but if I want to
exclude an entry, I can't use | grep -v, because mutt doesn't support
pipes within backticks. :-)
Follow-up:
mutt's backtick support does in fact
On Friday 05 September 2008 16:39, Jeremy Chadwick wrote:
Equally as frustrating, mutt's backtick support will only honour the
first line of input. If a backticked command returns multiple lines,
only the first is read; the rest are ignored. This makes using BSD find
annoying, since find
Hello,
I've been tracing the printf function from the FreeBSD 6.x libc... I'm trying
to figure out what mechanism transfers the data from the processes FILE to
the system so it's written out to the screen...
From my findings I get to a function __sfvwrite(FILE,buf) {}
however this just
On Thu, 30 Nov 2006, Christopher Olsen wrote:
Hello,
I've been tracing the printf function from the FreeBSD 6.x libc... I'm trying
to figure out what mechanism transfers the data from the processes FILE to
the system so it's written out to the screen...
From my findings I get to a function
a couple
of seconds.
I have been looking through the archives and through some other drivers ( for
example randomdev.c uses a kthread and printf's from it ). I found a version
of randomdev.c with google that lock's Giant while calling printf, but
randomdev.c in my src-tree has no locking
On Sat, 8 Feb 2003 22:13:32 + (UTC) in lucky.freebsd.hackers, Auge Mike wrote:
Hi all,
I was trying to know how printf works in FreeBSD... I hvae reached to this
point :
#define _write(fd, s, n) \
__syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n))
I'am
Hi,
First of all, Thanks to all of you for your help and support.
I have tried to go deeper and deeper to find out how printf works. ((( Of
course the aim of trying to understand the printf, is to understand how
the internals of the BSD kernel work))) till i've faced the following
function
Hi all,
I was trying to know how printf works in FreeBSD... I hvae reached to this
point :
#define _write(fd, s, n) \
__syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n))
I'am not really familiar with the way FreeBSD handle interrupts. I like from
any one of you to tell me what
On Mon, 30 Sep 2002, Brooks Davis wrote:
On Mon, Sep 30, 2002 at 06:36:39PM -0700, Nate Lawson wrote:
What's the portable way of printing an off_t? It should work on Linux and
FreeBSD. Linux seems to recommend casting the off_t to intmax_t which
isn't present in FreeBSD. This is in
What's the portable way of printing an off_t? It should work on Linux and
FreeBSD. Linux seems to recommend casting the off_t to intmax_t which
isn't present in FreeBSD. This is in usermode.
Thanks,
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the
On Mon, Sep 30, 2002 at 06:36:39PM -0700, Nate Lawson wrote:
What's the portable way of printing an off_t? It should work on Linux and
FreeBSD. Linux seems to recommend casting the off_t to intmax_t which
isn't present in FreeBSD. This is in usermode.
In current, intmax_t is defined in
hi,
This patch fixes *printf() family routines to correctly handle
grouping for both decimals and floats. Current version of printf()
supports grouping for decimals only.
Yes, I know it looks like more hackish way, so other opinions are
welcome!
Since printf() is widely used and quite
On 10 Nov, Terry Lambert wrote:
A simple question:
Does the kernel function printf() flushes the output immediately, or it is
possible some data is buffered somewhere and gets lost without printing
to the console? like the corresponding funtion in the c library.
There is no buffering
On 10 Nov, Warner Losh wrote:
In message [EMAIL PROTECTED] Zhenhai
Duan writes:
: Does the kernel function printf() flushes the output immediately, or it is
: possible some data is buffered somewhere and gets lost without printing
: to the console? like the corresponding funtion in the c
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
: printf("foo do foo\n");
: crash_here();
: printf("after the crash\n");
:
: And never see the statement "foo do foo\n";
: Is that correct?
Yes. But I had a lot of printfs in the code that I was debug
On 9 Nov, Alfred Perlstein wrote:
* Zhenhai Duan [EMAIL PROTECTED] [001109 21:09] wrote:
A simple question:
Does the kernel function printf() flushes the output immediately, or it is
possible some data is buffered somewhere and gets lost without printing
to the console? like
Does the kernel function printf() flushes the output immediately, or it is
possible some data is buffered somewhere and gets lost without printing
to the console? like the corresponding funtion in the c library.
It's not buffered afaik.
Actually my experince in writing drivers
Is there is way that I could perhaps demonstrate my reasoning,
such that it might be satisfactory to you?
No.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the
[EMAIL PROTECTED] writes:
[...]
Jessem.
Amazing what people will do to evade killfiles. Plonk.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On 10 Nov, Mike Smith wrote:
Is there is way that I could perhaps demonstrate my reasoning,
such that it might be satisfactory to you?
No.
Then, should I take it you concede the point?
Jessem.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On 10 Nov, Mike Smith wrote:
Is there is way that I could perhaps demonstrate my reasoning,
such that it might be satisfactory to you?
No.
Then, should I take it you concede the point?
No.
--
... every activity meets with opposition, everyone who acts has his
rivals and
Thanks for all of your replies. The reason I asked this question is that I
really saw some incomplete print out on FreeBSD 3.3. My intuition is that
the printout is buffered some where, otherwise, I would expect either
there is a complete printout, or no printout at all.
--Zhenhai
On Fri, 10 Nov
A simple question:
Does the kernel function printf() flushes the output immediately, or it is
possible some data is buffered somewhere and gets lost without printing
to the console? like the corresponding funtion in the c library.
There is no buffering comparable to that of the stdio
In message [EMAIL PROTECTED] Zhenhai Duan
writes:
: Does the kernel function printf() flushes the output immediately, or it is
: possible some data is buffered somewhere and gets lost without printing
: to the console? like the corresponding funtion in the c library.
Yes. It can be buffered
A simple question:
Does the kernel function printf() flushes the output immediately, or it is
possible some data is buffered somewhere and gets lost without printing
to the console? like the corresponding funtion in the c library.
Thanks.
--Zhenhai
To Unsubscribe: send mail to [EMAIL
* Zhenhai Duan [EMAIL PROTECTED] [001109 21:09] wrote:
A simple question:
Does the kernel function printf() flushes the output immediately, or it is
possible some data is buffered somewhere and gets lost without printing
to the console? like the corresponding funtion in the c library.
It's
At 6:27 PM -0400 9/7/00, John Doh! wrote:
Hello to you am I C coder who to wish write programs we cannot
exploit via code such as below.
main(int argc, char **argv)
{
if(argc 1) {
printf(gettext("usage: %s filename\n"),argv[0]);
exit(0);
}
printf("normal exe
Hello to you am I C coder who to wish write programs we cannot exploit via
code such as below.
main(int argc, char **argv)
{
if(argc 1) {
printf(gettext("usage: %s filename\n"),argv[0]);
exit(0);
}
printf("normal executio
ssage had.
Typically you want to use positional arguments with printf so that your
gettext responses can reorder things to get better results, but the same
basically applies.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not becau
Hello to you am I C coder who to wish write programs we cannot exploit via
code such as below.
main(int argc, char **argv)
{
if(argc 1) {
printf(gettext("usage: %s filename\n"),argv[0]);
exit(0);
}
printf("normal execution proceeds...\n");
From: Alfred Perlstein [EMAIL PROTECTED]
To: John Doh! [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: How to stop problems from printf
Date: Thu, 7 Sep 2000 19:33:14 -0700
* John Doh! [EMAIL PROTECTED] [000907 19:28] wrote:
Hello to you am I C coder who to wish
In message [EMAIL PROTECTED] "John Doh!" writes:
: Issue is must be getting format string from "untrusted" place, but want to
: limit substitution of %... to the substitution of say in example the
: argv[0], but to not do others so that say given "usage: %s filename %p" %p
: not interpret but
N arguments in the same order that the
original message had.
gettext() doesnt take any additional arguments, AFAIK it just munges the
string. The argument substitution was being done by printf() in the
example given.
"usage: %s filename" - "blurgle: %s flobodob"
But if you're looking up in an
In message [EMAIL PROTECTED] Kris
Kennaway writes:
: gettext() doesnt take any additional arguments, AFAIK it just munges the
: string. The argument substitution was being done by printf() in the
: example given.
Right. You know how many args are expected, since you know printf.
: The only
On Thu, 7 Sep 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] Kris
Kennaway writes:
: gettext() doesnt take any additional arguments, AFAIK it just munges the
: string. The argument substitution was being done by printf() in the
: example given.
Right. You know how many args
In message [EMAIL PROTECTED] Kris
Kennaway writes:
: It also needs to check they are all of the same type, as changing a %d to
: a %s for example could conceivably be exploitable. And you would have to
: forbid escaped % characters as well. Yeah, I think that would be
: doable. We probably
On Fri, 8 Sep 2000, Jan Knepper wrote:
I don't know what you are doing with the 'gettext' in the call to 'printf'.
Translate the string into a localized version. You can't just printf("%s",
gettext(...), args) because the arguments won't be printed, only the raw
string returned fr
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED]
Be sure to reply to that address.
Hello,
I use printf() function from my KLD for
debugging. Always, when the kernel call printf, I
see two same line, like :
Dec 9 15:40:10 techno /kernel: message
Dec 9 15:40
Alex writes:
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED]
Be sure to reply to that address.
Hello,
I use printf() function from my KLD for
debugging. Always, when the kernel call printf, I
see two same line, like :
Dec 9 15:40:10 techno /kernel: me
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED]
Be sure to reply to that address.
Hello,
I use printf() function from my KLD for
debugging. Always, when the kernel call printf, I
see two same line, like :
Dec 9 15:40:10 techno /kernel: message
Dec
Well, assume
u_int64_t foo = ~0;
printf("Foo is equal %qx\n",
produces
Foo is equal %qx
And
printf("Foo is equal %x\n");
produces:
../../i2o/i2o_drv.c:1260: warning: unsigned int format, different type
arg (arg 4)
You are damned if you do and damned if
90 matches
Mail list logo
