login
Search
| From | Subject | Date |
|---|---|---|
| Jeff Garzik | [PATCH 14/14] [ISDN] HiSax bkm_a8: convert to PCI hotplug API
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
---
drivers/isdn/hisax/Kconfig | 4 +-
drivers/isdn/hisax/Makefile | 2 +-
drivers/isdn/hisax/bkm_a8.c | 186 +++++++++++++++++++++++++++++-------------
drivers/isdn/hisax/config.c | 48 +-----------
4 files changed, 133 insertions(+), 107 deletions(-)
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index 36af79f..8e18f7c 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -298,8 +298,8...
| Aug 2, 8:37 am 2007 |
| Jeff Garzik | [PATCH 13/14] [ISDN] HiSax bkm_a8: convert to PCI hotplug API
---
drivers/isdn/hisax/Kconfig | 4 +-
drivers/isdn/hisax/Makefile | 2 +-
drivers/isdn/hisax/bkm_a8.c | 186 +++++++++++++++++++++++++++++-------------
drivers/isdn/hisax/config.c | 48 +-----------
4 files changed, 133 insertions(+), 107 deletions(-)
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index 36af79f..8e18f7c 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -298,8 +298,8 @@ config HISAX_BKM_A4T
settings.
config HIS...
| Aug 2, 8:37 am 2007 |
| Matthew Garrett | [PATCH] USB: Only enable autosuspend by default on certain d...
We're seeing a large number of problems with devices not appreciating
USB autosuspend, especially printers and scanners. According to
http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx only a
subset of drivers support it in Windows XP, meaning that most devices
are probably untested in this situation. This patch alters the behaviour
to match that of Windows. Userspace can still whitelist devices as
appropriate, and the set of classes supporting autosuspend probably
covers pretty mu...
| Aug 2, 7:56 pm 2007 |
| Daniel Ritz | REGRESSION: serial_cs broken by 8250 changes
commit 18a8bd949d6adb311ea816125ff65050df1f3f6e breaks serial_cs badly
with an oops, completely killing PCMCIA.
register_console() now calls console->early_setup(). which in case of
8250.c (the only user anyway) is serial8250_console_early_setup()
which is __init, calling 8250_early.c:serial8250_find_port_for_earlycon()
which is __init as well. boom.
the changelog mentions SERIAL_PORT_DFNS removal which happens to be
commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. but this got reverted
by co...
| Aug 2, 7:06 pm 2007 |
| Yinghai Lu | Re: REGRESSION: serial_cs broken by 8250 changes
Is there any flag or sign that init code has been released?
We could use that to prevent init code to be called after code is freed.
Thanks
Yinghai Lu
-
| Aug 2, 7:24 pm 2007 |
| Andrew Morton | Re: REGRESSION: serial_cs broken by 8250 changes
On Thu, 02 Aug 2007 16:24:42 -0700
If we can omit a function call without breaking anything then we shouldn't
have been calling that function at all ;)
It sounds like making serial8250_console_early_setup() and
serial8250_find_port_for_earlycon() non-__init will fix this.
-
| Aug 2, 7:35 pm 2007 |
| Andrew Morton | Re: REGRESSION: serial_cs broken by 8250 changes
On Fri, 3 Aug 2007 01:06:32 +0200
<head spins>
Sounds like you'd be the ideal person to propose a patch ;)
-
| Aug 2, 7:15 pm 2007 |
| Oleg Nesterov | [PATCH] do_sigaction: remove now unneeded recalc_sigpending()
With the recent changes, do_sigaction()->recalc_sigpending_and_wake() can
never clear TIF_SIGPENDING. Instead, it can set this flag and wake up the
thread without any reason. Harmless, but unneeded and wastes CPU.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
--- t/kernel/signal.c~ 2007-08-03 02:26:30.000000000 +0400
+++ t/kernel/signal.c 2007-08-03 02:28:50.000000000 +0400
@@ -2342,7 +2342,6 @@ int do_sigaction(int sig, struct k_sigac
rm_from_queue_full(&mask, &t->signal...
| Aug 2, 6:37 pm 2007 |
| Roland McGrath | Re: [PATCH] do_sigaction: remove now unneeded recalc_sigpend...
ACK. (We agreed months ago this was the thing to do.)
Thanks,
Roland
-
| Aug 2, 6:40 pm 2007 |
| Gabriel C | [PATCH] kernel-parameters.txt : watchdog.txt should be wdt.t...
Documentation/watchdog/watchdog.txt does not exist, it is Documentation/watchdog/wdt.txt
Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
---
Documentation/kernel-parameters.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index efdb42f..a326487 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1922,7 +1922,7 @@ and is betwee...
| Aug 2, 6:00 pm 2007 |
| Robert Hancock | Re: gcc fixed size char array initialization bug - known?
Because 5 characters will not fit in a 4 character array, even without
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
-
| Aug 2, 5:42 pm 2007 |
| Oleg Nesterov | [PATCH, RESEND] pi-futex: set PF_EXITING without taking ->...
It is a bit annoying that do_exit() takes ->pi_lock to set PF_EXITING.
All we need is to synchronize with lookup_pi_state() which saw this task
without PF_EXITING under ->pi_lock.
Change do_exit() to use spin_unlock_wait().
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Acked-by: Ingo Molnar <mingo@elte.hu>
--- t/kernel/exit.c~PF_EXIT 2007-06-19 17:09:15.000000000 +0400
+++ t/kernel/exit.c 2007-07-21 15:34:13.000000000 +0400
@@ -908,13 +908,13 @@ fastcall NORET_TYPE void do_e...
| Aug 2, 5:37 pm 2007 |
| Chakri n | OOPS in shrink_dcache_for_umount
Hi,
We are seeing this problem while unmounting file systems. It happens
once in a while.
I am able to grab the trace and core from linux-2.6.18-1.8.el5, but I
have observed the same problem with linux-2.6.20.1 kernel.
Has this problem fixed in recent kernel?
BUG: Dentry f7498f70{i=12803e,n=client72} still in use (1) [unmount of nfs 0:18]
------------[ cut here ]------------
kernel BUG at fs/dcache.c:615!
invalid opcode: 0000 [#1]
SMP
last sysfs file: /block/ram0/range
Modules linked in: n...
| Aug 2, 5:27 pm 2007 |
| Oleg Nesterov | [RFC, PATCH] handle the multi-threaded init's exit() properly
With or without this patch, multi-threaded init's are not fully supported, but
do_exit() is completely wrong. This becomes a real problem when we support pid
namespaces.
1. do_exit() panics when the main thread of /sbin/init exits. It should not
until the whole thread group exits. Move the code below, under the
"if (group_dead)" check.
Note: this means that forget_original_parent() can use an already dead
child_reaper()'s task_struct. This is OK for /sbin/init because
- do_wait...
| Aug 2, 5:20 pm 2007 |
| Roland McGrath | Re: [RFC, PATCH] handle the multi-threaded init's exit() pro...
This looks fine to me, though I don't know anything about the nsproxy bit.
Now that choose_new_parent is one trivial line, you might go on to get rid
of it and roll its one line into reparent_thread.
Thanks,
Roland
-
| Aug 2, 6:51 pm 2007 |
| Jeff Dike | [PATCH 6/6] UML - physmem code tidying
Tidying of the UML physical memory system. These are mostly style
fixes, however the includes were cleaned as well. This uncovered a
need for mem_user.h to be included in mode_kern_skas.h.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
--
arch/um/include/skas/mode_kern_skas.h | 3 +-
arch/um/kernel/physmem.c | 50 ++++++++++++++--------------------
2 files changed, 23 insertions(+), 30 deletions(-)
Index: linux-2.6.21-mm/arch/um/kernel/physmem.c
====================...
| Aug 2, 5:04 pm 2007 |
| Jeff Dike | [PATCH 5/6] UML - Stop saving process FP state
Throw out a lot of code dealing with saving and restoring
floating-point state. In skas mode, where processes run in a
different host process (and have a different register set), saving and
restoring floating-point state on kernel entry and exit is pointless.
This eliminates most of arch/um/os-Linux/sys-{i386,x86_64}/registers.c.
Most of what remained is now arch-indpendent, and can be moved up to
arch/um/os-Linux/registers.c. Both arches need the jmp_buf accessor
get_thread_reg, and i386 needs {...
| Aug 2, 5:04 pm 2007 |
| Jeff Dike | [PATCH 4/6] UML - Stop specially protecting kernel stacks
Map all of physical memory as executable to avoid having to change
stack protections during fork and exit.
unprotect_stack is now called only from MODE_TT code, so it is marked
as such.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
--
arch/um/include/kern_util.h | 2 ++
arch/um/kernel/init_task.c | 2 ++
arch/um/kernel/physmem.c | 2 +-
arch/um/kernel/process.c | 5 ++---
4 files changed, 7 insertions(+), 4 deletions(-)
Index: linux-2.6.21-mm/arch/um/kernel/phys...
| Aug 2, 5:04 pm 2007 |
| Jeff Dike | [PATCH 2/6] UML - Fix an IPV6 libc vs kernel symbol clash
On some systems, with IPV6 configured, there is a clash between the
kernel's in6addr_any and the one in libc.
This is handled in the usual (gross) way of defining the kernel symbol
out of the way on the gcc command line.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
--
arch/um/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-mm/arch/um/Makefile
===================================================================
--- linux-2.6.21-mm.orig/arch/um...
| Aug 2, 5:04 pm 2007 |
| Jeff Dike | [PATCH 3/6] UML - Fix nonremovability of watchdog
The UML watchdog driver was using the wrong config variable to control
whether it can be unloaded once active.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
--
arch/um/drivers/harddog_kern.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-mm/arch/um/drivers/harddog_kern.c
===================================================================
--- linux-2.6.21-mm.orig/arch/um/drivers/harddog_kern.c 2007-08-02 16:43:17.000000000 -0400
+++ linux-2.6.21-mm/arch/um...
| Aug 2, 5:04 pm 2007 |
| Jeff Dike | [PATCH 0/6] UML - Cleanups and small fixes for 2.6.24
These are more cleanups and small fixes. They should wait for 2.6.24.
Jeff
--
Work email - jdike at linux dot intel dot com
-
| Aug 2, 5:04 pm 2007 |
| Jeff Dike | [PATCH 1/6] UML - Stop using libc asm/page.h
Remove includes of asm/page.h from libc code. This header seems to be
disappearing, and UML doesn't make much use of it anyway.
The one use, PAGE_SHIFT in stub.h, is handled by copying the constant
from the kernel side of the house in common_offsets.h.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
--
arch/um/include/common-offsets.h | 1 +
arch/um/include/sysdep-i386/stub.h | 3 +--
arch/um/os-Linux/main.c | 1 -
arch/um/os-Linux/skas/mem.c | 1 -
arc...
| Aug 2, 5:04 pm 2007 |
| H. Peter Anvin | [GIT PULL] Additional x86 setup fixes
Hi Linus,
One more batch of x86setup bug fixes. Of these, one is a manifest bug
(EDID query failure), one is a non-manifest bug, and one is
documentation (Grub < 0.93 buggy.)
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git for-linus
Antonino A. Daplas (1):
[x86 setup] video setup: Fix VBE DDC reading
H. Peter Anvin (2):
[x86 setup] EDD: add missing =m constraint
[x86 setup] Document grub < 0.93 as broken
Documentation/C...
| Aug 2, 4:45 pm 2007 |
| Nico Erfurth | [PATCH 2.6.22] Adding drivers/usb/misc/iowarrior.c to the Ma...
This patch adds the new iowarrior module to the Makefile in drivers/usb.
Currently the module isn't build unless another driver from usb/misc is
selected.
Signed-off-by: Nico Erfurth <masta@perlgolf.de>
---
--- linux/drivers/usb/Makefile.orig 2007-08-02 21:54:16.000000000 +0200
+++ linux/drivers/usb/Makefile 2007-08-02 22:20:57.000000000 +0200
@@ -38,6 +38,7 @@ obj-$(CONFIG_USB_EMI26) += misc/
obj-$(CONFIG_USB_EMI62) += misc/
obj-$(CONFIG_USB_FTDI_ELAN) ...
| Aug 2, 4:25 pm 2007 |
| Sam Ravnborg | Re: [PATCH 2.6.22] Adding drivers/usb/misc/iowarrior.c to th...
Can we please just always vist misc like this:
obj-y := misc/
Then we do not need to repeat this stuff in both
drivers/usb/Makefile and drivers/usb/misc/Makefile
Thanks,
Sam
-
| Aug 2, 5:27 pm 2007 |
| Jesper Juhl | error: implicit declaration of function 'rcu_dereference' - ...
I get this build error with the current mainline git tree.
Let me know if further details are needed...
...
In file included from include/linux/sched.h:75,
from include/linux/smp_lock.h:5,
from include/linux/hardirq.h:5,
from include/linux/slub_def.h:13,
from include/linux/slab.h:116,
from include/linux/percpu.h:5,
from include/linux/rcupdate.h:41,
from include/linux/key.h:21,
...
| Aug 2, 3:57 pm 2007 |
| Adrian Bunk | Re: error: implicit declaration of function 'rcu_dereference...
-ENODOTCONFIG
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
| Aug 2, 4:13 pm 2007 |
| Jesper Juhl | Re: error: implicit declaration of function 'rcu_dereference...
Attached.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
| Aug 2, 4:16 pm 2007 |
| Jesper Juhl | Re: error: implicit declaration of function 'rcu_dereference...
Forget about this.
I thought I had a clean tree, but it turns out that I did not. I had
some local (buggy) changes in there that I had overlooked. I did
git reset --hard master
git clean -d
and now everything builds fine with that config.
Sorry about the noise.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
| Aug 2, 4:49 pm 2007 |
| Jesper Juhl | Re: error: implicit declaration of function 'rcu_dereference...
When I say "current mainline git tree" I mean that HEAD is at
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
| Aug 2, 4:10 pm 2007 |
| Guennadi Liakhovetski | gcc fixed size char array initialization bug - known?
Hi
I've run across the following gcc "feature":
char c[4] = "01234";
gcc emits a nice warning
warning: initializer-string for array of chars is too long
But do a
char c[4] = "0123";
and - a wonder - no warning. No warning with gcc 3.3.2, 3.3.5, 3.4.5,
4.1.2. I was told 4.2.x does produce a warning. Now do a
struct {
char c[4];
int i;
} t;
t.i = 0x12345678;
strcpy(t.c, c);
and t.i is silently corrupted. Just wanted to ask if this is known,
really...
Thanks
Gu...
| Aug 2, 3:55 pm 2007 |
| Jakub Jelinek | Re: gcc fixed size char array initialization bug - known?
4.2.x nor 4.3 doesn't warn either and it is correct not to warn about
perfectly valid code.
ISO C99 is very obvious in that the terminating '\0' (resp. L'\0') from
the string literal is only added if there is room in the array or if the
array has unknown size.
Jakub
-
| Aug 2, 7:42 pm 2007 |
| Jan Engelhardt | Re: gcc fixed size char array initialization bug - known?
Unfortunately, gcc 4.2.1 does not produce a warning for
char a[4] = "haha";
Jan
--
-
| Aug 2, 4:18 pm 2007 |
| Jan Engelhardt | Re: gcc fixed size char array initialization bug - known?
What does this have to do with the kernel? The string "0123" is
generally _five_ characters long, so c[4] is not enough.
Or use strncpy.
Jan
--
-
| Aug 2, 3:59 pm 2007 |
| Jesper Juhl | Re: gcc fixed size char array initialization bug - known?
I believe Guennadi's point is that gcc does not warn about it in the
case of c[4] = "0123"; but only in the case of c[4] = "01234" - so if
we do have such initializations in the kernel we may have some bugs
hiding there that gcc doesn't warn us about.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
| Aug 2, 4:03 pm 2007 |
| Guennadi Liakhovetski | Re: gcc fixed size char array initialization bug - known?
Exactly. Think of all structs with fixed-length char arrays (various
device name fields, etc.) static instances of which re scattered across
all possible drivers... Usually those strings should be long "enough", but
if someone manages to exactly hit the length, there won't be a warning.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
| Aug 2, 4:15 pm 2007 |
| Al Viro | Re: gcc fixed size char array initialization bug - known?
Who said it's a bug? Or that all arrays of char have to contain '\0'
anywhere in them?
-
| Aug 2, 4:10 pm 2007 |
| Jesper Juhl | Re: gcc fixed size char array initialization bug - known?
I was simply trying to explain what I thought Guennadi meant. I was
not commenting on whether or not there's a bug there.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
| Aug 2, 4:12 pm 2007 |
| Andi Kleen | Re: gcc fixed size char array initialization bug - known?
It's required by the C standard.
6.7.8.14 of C99:
``
An array of character type may be initialized by a character string literal, optionally
enclosed in braces. Successive characters of the character string literal (including the
terminating null character if there is room or if the array is of unknown size) initialize the
elements of the array.
''
Note the "if there is room".
I believe the rationale is that it still allows to conveniently initialize
non zero terminated strings.
-Andi
...
| Aug 2, 5:06 pm 2007 |
| Guennadi Liakhovetski | Re: gcc fixed size char array initialization bug - known?
Right, I accept that it will compile, but I don't understand why "01234"
produces a warning and "0123" doesn't? Don't think C99 says anything about
that. And, AFAIU, using structs with fixed-size char array we more or less
rely on the compiler warning us if anyone initializes it with too long a
string.
Also interesting, that with
char c[4] = "012345";
the compiler warns, but actually allocates a 6-byte long array...
Thanks
Guennadi
---
Guennadi Liakhovetski
-
| Aug 2, 4:36 pm 2007 |
| Stefan Richter | Re: gcc fixed size char array initialization bug - known?
Off-topic here, but: sizeof c / sizeof *c == 4.
--
Stefan Richter
-=====-=-=== =--- ---==
http://arcgraph.de/sr/
-
| Aug 2, 6:31 pm 2007 |
| Guennadi Liakhovetski | Re: gcc fixed size char array initialization bug - known?
Don't think it is OT here - kernel depends on gcc. And, what I meant, is,
that gcc places all 7 (sorry, not 6 as I said above) characters in the
.rodata section of the compiled object file. Of course, it doesn't mean,
that c is 7 characters long.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
| Aug 2, 6:51 pm 2007 |
| Al Viro | Re: gcc fixed size char array initialization bug - known?
So gcc does that kind of recovery, after having warned you. Makes sense,
as long as it's for ordinary variables (and not, say it, struct fields) -
you get less likely runtime breakage on the undefined behaviour (e.g.
passing c to string functions). So gcc has generated some padding between
the global variables, that's all.
It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c)
means nasal demon country for you.
Now, if gcc does that for similar situation with struct fields...
| Aug 2, 7:09 pm 2007 |
| Guennadi Liakhovetski | Re: gcc fixed size char array initialization bug - known?
Haha, funny. You, certainly, may think whatever you want, I'm anyway
greatful to you and to all the rest for the trouble you took to find THE
quote that actually answers the question.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
| Aug 2, 7:30 pm 2007 |
| Stefan Richter | Re: gcc fixed size char array initialization bug - known?
No, the fact that the full 012345\0 ends up in the object file is
...since only 0123 will get into c at runtime, i.e. a 4 bytes long array
without \0 appendix or other extraordinary padding.
#include <stdio.h>
#include <string.h>
int main()
{
char c[4] = "012345";
printf("%d %d _%s_\n", sizeof c / sizeof *c, strlen(c), c);
return 0;
}
$ ./a.out
4 8 _01230®¿_
$ strings a.out |grep 0123
012345
--
Stefan Richter
-=====-=-=== =--- ---==
http://arcgraph.de/sr/
...
| Aug 2, 7:27 pm 2007 |
| Stefan Richter | Re: gcc fixed size char array initialization bug - known?
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
Given the respective command line switches, gcc does warn in some cases
where it is guesswork whether what you typed is what you intended. For
example
if (i = j())
is reason for gcc to warn even if that might exactly be what you wanted.
However this construct can easily be annotated as
if ((i = j()))
to show to gcc and to carbon-based bipedals that you indeed wanted this.
Now there ...
| Aug 2, 6:15 pm 2007 |
| Guennadi Liakhovetski | Re: gcc fixed size char array initialization bug - known?
Robert, Stefan, I am sorry, I think, you are VERY wrong here. There is no
"even" and no guessing. The "string" DOES include a terminating '\0'. It
is EQUIVALENT to {'s', 't', 'r', 'i', 'n', 'g', '\0'}. And it contains
SEVEN characters. Please, re-read your K&R. Specifically, the Section
"Initialization" in the "Function and Program Structure" chapter (section
4.9 in my copy), the paragraph about initialization with a string, which I
quoted in an earlier email.
And, Stefan, there is a ...
| Aug 2, 6:36 pm 2007 |
| Al Viro | Re: gcc fixed size char array initialization bug - known?
Read the fucking standard. In particular, notice that meaning of
string literals outside of initializer is *defined* via that in
initializers. IOW, string literals contain _nothing_ - not '\0', not
anything else. The entire reason why use of string literal ends up
with anon array containing \0 is exactly there - it's "how do we
determine the actual length of array of character with unknown length
initialized by string literal". _That_ is where \0 comes from.
And yes, all quotes you've given a...
| Aug 2, 7:02 pm 2007 |
| Randy Dunlap | Re: gcc fixed size char array initialization bug - known?
We are actually a bit beyond traditional K&R, fwiw.
C99 spec that Al referred you to (available for around US$18 as a pdf)
says in 6.7.8, para. 14 (where Al said):
"An array of character type may be initialized by a character string literal, optionally
enclosed in braces. Successive characters of the character string literal (including the
terminating null character if there is room or if the array is of unknown size) initialize the
elements of the array."
---
~Randy
*** Remember to u...
| Aug 2, 6:54 pm 2007 |
| Guennadi Liakhovetski | Re: gcc fixed size char array initialization bug - known?
Wow... So, the terminating '\0' in the string constant IS "special" and
"optional"... Ok, then, THIS does answer my question, THIS I can
understand, and, ghm, accept...
Thanks to all who tried to explain this to me and sorry it took so long...
Thanks
Guennadi
---
Guennadi Liakhovetski
-
| Aug 2, 7:26 pm 2007 |
| previous day | today | next day |
|---|---|---|
| August 1, 2007 | August 2, 2007 | August 3, 2007 |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| majkls | sys_chroot+sys_fchdir Fix |
| Paul Mackerras | Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
