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 "0x0"
http://people.freebsd.org/~sbruno/subr_prf.txt
Sean
si
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 dinoe
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"
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"
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 glib
_DMA(2);
>>>^~~
>>> @/dev/drm/mga_drv.h:291:35: note: expanded from:
>>>DRM_INFO( " space=0x%x req=0x%Zx\n", \
>>>
v.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
^
> @/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
BEGIN_DMA(2);
^~~
@/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, ...) pr
> 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
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 co
>> 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 conso
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 co
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 a
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
d to printf'ing any typedefed integer type using
>>> "%jd" 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
quot;%jd" 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
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
&g
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 i
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 i
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 somewhe
On Sun, Jun 5, 2011 at 11:13 AM, Ben Laurie 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, 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
# define INT_64_T_FMT "%ld"
#else
# define INT_64_T_FMT "
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
# define INT_64_T_FMT "%ld"
#else
# define INT_64_T_FMT "%lld"
#endif
but I have no idea whe
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_
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
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 rpcb
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 pr
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) doe
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 drive
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
r...@olimpico-freebsd:/usr/obj/usr/src/sys/GENERIC
On Mon, Nov 22, 2010 at 5:38 AM, Dmitry Krivenok
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'
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
On 11/22/10, Andriy Gapon wrote:
> on 22/11/2010 01:18 Paul B Mahol said the following:
>> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon 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
>
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 wrote:
> > On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
> >> on 21/11/2010 13:07 Paul B Mahol said the following:
> >>> This patch remo
on 22/11/2010 01:18 Paul B Mahol said the following:
> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon 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 for usel
On Sun, Nov 21, 2010 at 9:18 PM, Paul B Mahol wrote:
> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon 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. So
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon 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/
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.
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
f I submit a patch...
>
> What 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 i
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 s
ust ditch the cast+%x and use %p? I don't have an i386 system
> to test on, and I don't want to break anything if I submit a patch...
What is actually being printed isn't a pointer, but the difference
between two pointers (I assume from your comments; the code included
isn'
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 t
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
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 re
ilding a list of mailboxes 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
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
t; 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
cal to GNU find), 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
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 ge
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) {}
ter 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 n
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&#x
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)
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
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 i
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 s
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 th
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
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 de
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 cor
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 t
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 bu
> 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 th
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
> 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
r
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]
[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
>
> 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 t
On 10 Nov, Mike Smith wrote:
>> >> 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
> >> 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 buf
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 w
* 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 fun
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
ents in the same order that the
> original message 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
riv
> 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]);
> &g
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"
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 pr
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 shou
I don't know what you are doing with the 'gettext' in the call to 'printf'.
However for printf usage I would always limit the size of a string being
displayed with "%s", thus as "%-.80s" for instance.
I would *never* do:
printf ( argv [ 0 ] );
Since ar
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.
>
>
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.
: Th
> Fix gettext to only allow 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" -> "
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
>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:2
* John Doh! <[EMAIL PROTECTED]> [000907 19:28] 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) {
> >
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);
>}
>p
> 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 :
> De
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
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:
Dec 9 15:40:1
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 you do
93 matches
Mail list logo
