Re: gcc fixed size char array initialization bug - known?
Jakub Jelinek wrote: > 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. I would say C99 is /explicit/ in this regard. It doesn't seem like an overly /obvious/ language feature to me. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007 00:09:15 +0100, "Al Viro" <[EMAIL PROTECTED]>
said:
> On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote:
> > On Fri, 3 Aug 2007, Stefan Richter wrote:
> >
> > > Guennadi Liakhovetski wrote:
> > > > with
> > > >
> > > > char c[4] = "012345";
> > > >
> > > > the compiler warns, but actually allocates a 6-byte long array...
> > >
> > > Off-topic here, but: sizeof c / sizeof *c == 4.
> >
> > 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.
>
> 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, you'd
> have a cause to complain.
Hi!
(It took me a while before I understood that that last that referred to
padding inside a struct generated by gcc due to overlong initializers.)
But from the rest of the thread it seems that some people expect the
compiler to warn about the following...
struct {char c[4];} s1 = {"abcd"};
It doesn't. Of course if one wants to be warned in such cases
(initialisation
of a character array of specified length using a string constant) one
could
tell the compiler that the 0 at the end should really be there:
struct {char c[4];} s2 = {"abcd" "\0"};
Writing it like this will give them the expected warning.
Greetings,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Aug 3 2007 01:30, Guennadi Liakhovetski wrote: >On Fri, 3 Aug 2007, Al Viro wrote: > >> It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c) >> means nasal demon country for you. > >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. So back to the topic - if you want to check whether the kernel 'accidentally' uses char foo[4] = "abcd"; change gcc or sparse to warn about this and then sort out the pieces which are good. :) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 2007-08-03 at 11:40 +0800, WANG Cong wrote:
> On Fri, Aug 03, 2007 at 08:47:56AM +0530, Satyam Sharma wrote:
[]
> >While we're talking of null-termination of strings, then I bet you
> >generally want to be using strlcpy(), really. Often strncpy() isn't
> >what you want. Of course, if that buffer isn't a string at all, then
> >you should be using memfoo() functions and not strbar() ones in the
> >first place ...
>
> Afaik, strlcpy() and strlcat() are NOT standard C library functions.
Yes, because they are not old enough as they are results of lessons
learned with strncpy() and strcpy() and other buffer overflows.
> But, I know, they are available in Linux kernel. ;) And yes, they
> are better than strn{cpy,cat}().
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 2007-08-03 at 11:40 +0800, WANG Cong wrote:
On Fri, Aug 03, 2007 at 08:47:56AM +0530, Satyam Sharma wrote:
[]
While we're talking of null-termination of strings, then I bet you
generally want to be using strlcpy(), really. Often strncpy() isn't
what you want. Of course, if that buffer isn't a string at all, then
you should be using memfoo() functions and not strbar() ones in the
first place ...
Afaik, strlcpy() and strlcat() are NOT standard C library functions.
Yes, because they are not old enough as they are results of lessons
learned with strncpy() and strcpy() and other buffer overflows.
But, I know, they are available in Linux kernel. ;) And yes, they
are better than strn{cpy,cat}().
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Aug 3 2007 01:30, Guennadi Liakhovetski wrote: On Fri, 3 Aug 2007, Al Viro wrote: It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c) means nasal demon country for you. 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. So back to the topic - if you want to check whether the kernel 'accidentally' uses char foo[4] = abcd; change gcc or sparse to warn about this and then sort out the pieces which are good. :) Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Jakub Jelinek wrote: 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. I would say C99 is /explicit/ in this regard. It doesn't seem like an overly /obvious/ language feature to me. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007 00:09:15 +0100, Al Viro [EMAIL PROTECTED]
said:
On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote:
On Fri, 3 Aug 2007, Stefan Richter wrote:
Guennadi Liakhovetski wrote:
with
char c[4] = 012345;
the compiler warns, but actually allocates a 6-byte long array...
Off-topic here, but: sizeof c / sizeof *c == 4.
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.
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, you'd
have a cause to complain.
Hi!
(It took me a while before I understood that that last that referred to
padding inside a struct generated by gcc due to overlong initializers.)
But from the rest of the thread it seems that some people expect the
compiler to warn about the following...
struct {char c[4];} s1 = {abcd};
It doesn't. Of course if one wants to be warned in such cases
(initialisation
of a character array of specified length using a string constant) one
could
tell the compiler that the 0 at the end should really be there:
struct {char c[4];} s2 = {abcd \0};
Writing it like this will give them the expected warning.
Greetings,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: 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." 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... You should not have asked in the first place. The declaration char c[4] = "abcd" is perfectly valid. There is no cause for debate about it :) Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
On Thu, 2 Aug 2007, Robert Hancock wrote:
Because 5 characters will not fit in a 4 character array, even without the
null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
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 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.
Guennadi,
The declaration
char c[4] = "abcd";
is perfectly valid.
If other versions of gcc give warnings with that declaration, then those
warnings may be useful but it does not mean to say that other versions of
gcc follow the standards or not.
K is good as a reference but not as an authority. They drafted the book
as an informal specification of C. C has evolved throughout the decades.
The current standard is C99. And as quoted earlier in this thread,
character array initializations are described as:
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.
The gcc warning you see on other versions is a warning that does not have
anything to do with the current C standard. The other versions of gcc that
do not emit such character initialization warnings do not mean that they
are buggy in that respect.
IOW, the fact that you did not see the warning in a certain gcc version
does not mean that it is buggy in that respect.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 08:47:56AM +0530, Satyam Sharma wrote:
>
>
>On Thu, 2 Aug 2007, Jan Engelhardt wrote:
>
>> On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
>> > [...]
>> >
>> >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...
>>
>> 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.
>
>
>
>While we're talking of null-termination of strings, then I bet you
>generally want to be using strlcpy(), really. Often strncpy() isn't
>what you want. Of course, if that buffer isn't a string at all, then
>you should be using memfoo() functions and not strbar() ones in the
>first place ...
Afaik, strlcpy() and strlcat() are NOT standard C library functions.
But, I know, they are available in Linux kernel. ;) And yes, they
are better than strn{cpy,cat}().
Regards.
--
_ /|
\'o.O'
=(___)=
U
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Jan Engelhardt wrote:
> On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
> > [...]
> >
> > 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...
>
> 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.
While we're talking of null-termination of strings, then I bet you
generally want to be using strlcpy(), really. Often strncpy() isn't
what you want. Of course, if that buffer isn't a string at all, then
you should be using memfoo() functions and not strbar() ones in the
first place ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote: > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On 08/03/2007 01:26 AM, Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: 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." 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... Ah come on, it would be great fun to now make the argument that that quoted bit doesn't actually say wat should happen when there's _no_ room for the terminating null character... Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007, Al Viro wrote: > It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c) > means nasal demon country for you. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Al Viro wrote:
> On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote:
>> On Fri, 3 Aug 2007, Stefan Richter wrote:
>>
>>> Guennadi Liakhovetski wrote:
with
char c[4] = "012345";
the compiler warns, but actually allocates a 6-byte long array...
>>> Off-topic here, but: sizeof c / sizeof *c == 4.
>> 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.
>
> 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.
No, the fact that the full 012345\0 ends up in the object file is
apparently unrelated to what happens to the variable c...
> 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, you'd have
> a cause to complain.
...since only 0123 will get into c at runtime, i.e. a 4 bytes long array
without \0 appendix or other extraordinary padding.
#include
#include
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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Randy Dunlap wrote: > 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." 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote: > On Fri, 3 Aug 2007, Stefan Richter wrote: > > > Guennadi Liakhovetski wrote: > > > with > > > > > > char c[4] = "012345"; > > > > > > the compiler warns, but actually allocates a 6-byte long array... > > > > Off-topic here, but: sizeof c / sizeof *c == 4. > > 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. 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, you'd have a cause to complain. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 03:54:34PM -0700, Randy Dunlap wrote:
> >
> > And, Stefan, there is a perfect way to specify a "0123" without the '\0' -
> > {'0', '1', '2', '3'}.
>
> We are actually a bit beyond traditional K, fwiw.
Not in that area - this behaviour is precisely what traditional K
had all along. Unchanged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 12:36:40AM +0200, Guennadi Liakhovetski wrote: > On Thu, 2 Aug 2007, Robert Hancock wrote: > > > Because 5 characters will not fit in a 4 character array, even without the > > null terminator. > > On Fri, 3 Aug 2007, Stefan Richter wrote: > > > How should gcc know whether you actually wanted that char foo[len] to > > contain a \0 as last element? > > 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'. 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 are correct. You are blatantly ignoring the context even when you are including all relevant parts into the quoted text. This stuff hadn't changed since K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007, Stefan Richter wrote: > Guennadi Liakhovetski wrote: > > with > > > > char c[4] = "012345"; > > > > the compiler warns, but actually allocates a 6-byte long array... > > Off-topic here, but: sizeof c / sizeof *c == 4. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007 00:36:40 +0200 (CEST) Guennadi Liakhovetski wrote:
> On Thu, 2 Aug 2007, Robert Hancock wrote:
>
> > Because 5 characters will not fit in a 4 character array, even without the
> > null terminator.
>
> On Fri, 3 Aug 2007, Stefan Richter wrote:
>
> > How should gcc know whether you actually wanted that char foo[len] to
> > contain a \0 as last element?
>
> 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 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 perfect way to specify a "0123" without the '\0' -
> {'0', '1', '2', '3'}.
We are actually a bit beyond traditional K, 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 use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(off-topic) Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
> Robert, Stefan, I am sorry, I think, you are VERY wrong here.
You meant to say "C99 is very wrong".
> And, Stefan, there is a perfect way to specify a "0123" without the '\0' -
> {'0', '1', '2', '3'}.
C99 says char c[4] = "0123"; is a perfect way to say char c[4] = {'0',
'1', '2', '3'};. Do you want gcc to choose otherwise and ban the former
of the two idioms?
--
Stefan Richter
-=-=-=== =--- ---==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Robert Hancock wrote:
> Because 5 characters will not fit in a 4 character array, even without the
> null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
> How should gcc know whether you actually wanted that char foo[len] to
> contain a \0 as last element?
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 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 perfect way to specify a "0123" without the '\0' -
{'0', '1', '2', '3'}.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: > with > > char c[4] = "012345"; > > the compiler warns, but actually allocates a 6-byte long array... Off-topic here, but: sizeof c / sizeof *c == 4. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: > On Thu, 2 Aug 2007, Andi Kleen wrote: >> 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. > > 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 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 is no nice way to make an annotation that says "look, I'm going to initialize an array of char with a string literal now, and the resulting array will contain a non-zero member as last element, and I mean it". And since there is no such annotation possible, gcc does not warn and demand that you annotate the perfectly valid and 100% spec-compliant construct char a[4] = "1234";. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Andi Kleen wrote: Guennadi Liakhovetski <[EMAIL PROTECTED]> writes: char c[4] = "0123"; and - a wonder - no warning. 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. 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 Because 5 characters will not fit in a 4 character array, even without the null terminator. 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 -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Al Viro wrote:
> On Thu, Aug 02, 2007 at 10:26:37PM +0200, Guennadi Liakhovetski wrote:
> >
> > Worse yet, K explicitely writes:
> >
> >
> >
> > char pattern[] = "ould";
> >
> > is a shorthand for the longer but equivalent
> >
> > char pattern[] = { 'o', 'u', 'l', 'd', '\0' };
> >
> >
> >
> > In the latter spelling gcc < 4.2 DOES warn too.
>
> Does warn for what? Array with known size? Sure, so it should - you
> have excess initializer list elements.
>
> Note the [] in the quoted - it does matter.
>
> Again, it's perfectly legitimate to use string literal to initialize
> any kind of array of character type. \0 goes there only if there's
> space for it; if array size is unknown, the space is left. That's it.
Sure. Doing 'char c[4] = "01234";' is just like doing '"0123"': only
those bytes, for which there's space in the array go in, everything makes
perfect sense. What doesn't make sense to me though, is that in the former
case gcc warns, but not in the latter.
Maybe you're right in your interpretation of the standard / K, but it
doesn't still make it logical to me, sorry. I always thought "0123" was 5
bytes long (ok, ascii) and the terminating '\0' was an integral part of
the string, no different from any other character, and not some optional
token. Thus all the charecters should be handled equally.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 10:26:37PM +0200, Guennadi Liakhovetski wrote:
>
> Worse yet, K explicitely writes:
>
>
>
> char pattern[] = "ould";
>
> is a shorthand for the longer but equivalent
>
> char pattern[] = { 'o', 'u', 'l', 'd', '\0' };
>
>
>
> In the latter spelling gcc < 4.2 DOES warn too.
Does warn for what? Array with known size? Sure, so it should - you
have excess initializer list elements.
Note the [] in the quoted - it does matter.
Again, it's perfectly legitimate to use string literal to initialize
any kind of array of character type. \0 goes there only if there's
space for it; if array size is unknown, the space is left. That's it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Al Viro wrote:
> On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote:
> > But do a
> >
> > char c[4] = "0123";
> >
> > and - a wonder - no warning.
>
> And this is a correct behaviour. You get a valid initialier for array;
> see 6.7.8[14] for details. Moreover, that kind of code is often
What is 6.7.8[14]? If you're referring to the ANSI standard, then,
unfortunately, I don't have it.
> quite deliberate.
Worse yet, K explicitely writes:
char pattern[] = "ould";
is a shorthand for the longer but equivalent
char pattern[] = { 'o', 'u', 'l', 'd', '\0' };
In the latter spelling gcc < 4.2 DOES warn too.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Andi Kleen wrote: > Guennadi Liakhovetski <[EMAIL PROTECTED]> writes: > > > char c[4] = "0123"; > > and - a wonder - no warning. > > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote: >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 Unfortunately, gcc 4.2.1 does not produce a warning for char a[4] = "haha"; Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Al Viro wrote: > On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote: > > But do a > > > > char c[4] = "0123"; > > > > and - a wonder - no warning. > > And this is a correct behaviour. You get a valid initialier for array; > see 6.7.8[14] for details. Moreover, that kind of code is often > quite deliberate. But why 4.2 warns? Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Jesper Juhl wrote: > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On 02/08/07, Al Viro <[EMAIL PROTECTED]> wrote: > On Thu, Aug 02, 2007 at 10:03:03PM +0200, Jesper Juhl wrote: > > 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. > > Who said it's a bug? Or that all arrays of char have to contain '\0' > anywhere in them? > 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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski <[EMAIL PROTECTED]> writes: > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 10:03:03PM +0200, Jesper Juhl wrote: > 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. Who said it's a bug? Or that all arrays of char have to contain '\0' anywhere in them? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote:
> But do a
>
> char c[4] = "0123";
>
> and - a wonder - no warning.
And this is a correct behaviour. You get a valid initialier for array;
see 6.7.8[14] for details. Moreover, that kind of code is often
quite deliberate.
>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...
strcpy() from array that doesn't contain 0 is an undefined behaviour,
nothing new about that...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On 02/08/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
> >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...
>
> 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.
>
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 <[EMAIL PROTECTED]>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
>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...
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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
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...
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
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On 02/08/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
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...
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.
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 [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote:
But do a
char c[4] = 0123;
and - a wonder - no warning.
And this is a correct behaviour. You get a valid initialier for array;
see 6.7.8[14] for details. Moreover, that kind of code is often
quite deliberate.
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...
strcpy() from array that doesn't contain 0 is an undefined behaviour,
nothing new about that...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 10:03:03PM +0200, Jesper Juhl wrote: 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. Who said it's a bug? Or that all arrays of char have to contain '\0' anywhere in them? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On 02/08/07, Al Viro [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 10:03:03PM +0200, Jesper Juhl wrote: 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. Who said it's a bug? Or that all arrays of char have to contain '\0' anywhere in them? 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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski [EMAIL PROTECTED] writes: 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. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Jesper Juhl wrote: 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. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote: 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 Unfortunately, gcc 4.2.1 does not produce a warning for char a[4] = haha; Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Al Viro wrote: On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote: But do a char c[4] = 0123; and - a wonder - no warning. And this is a correct behaviour. You get a valid initialier for array; see 6.7.8[14] for details. Moreover, that kind of code is often quite deliberate. But why 4.2 warns? Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Andi Kleen wrote: Guennadi Liakhovetski [EMAIL PROTECTED] writes: char c[4] = 0123; and - a wonder - no warning. 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. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Al Viro wrote:
On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote:
But do a
char c[4] = 0123;
and - a wonder - no warning.
And this is a correct behaviour. You get a valid initialier for array;
see 6.7.8[14] for details. Moreover, that kind of code is often
What is 6.7.8[14]? If you're referring to the ANSI standard, then,
unfortunately, I don't have it.
quite deliberate.
Worse yet, KR explicitely writes:
quote
char pattern[] = ould;
is a shorthand for the longer but equivalent
char pattern[] = { 'o', 'u', 'l', 'd', '\0' };
/quote
In the latter spelling gcc 4.2 DOES warn too.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 10:26:37PM +0200, Guennadi Liakhovetski wrote:
Worse yet, KR explicitely writes:
quote
char pattern[] = ould;
is a shorthand for the longer but equivalent
char pattern[] = { 'o', 'u', 'l', 'd', '\0' };
/quote
In the latter spelling gcc 4.2 DOES warn too.
Does warn for what? Array with known size? Sure, so it should - you
have excess initializer list elements.
Note the [] in the quoted - it does matter.
Again, it's perfectly legitimate to use string literal to initialize
any kind of array of character type. \0 goes there only if there's
space for it; if array size is unknown, the space is left. That's it.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Al Viro wrote:
On Thu, Aug 02, 2007 at 10:26:37PM +0200, Guennadi Liakhovetski wrote:
Worse yet, KR explicitely writes:
quote
char pattern[] = ould;
is a shorthand for the longer but equivalent
char pattern[] = { 'o', 'u', 'l', 'd', '\0' };
/quote
In the latter spelling gcc 4.2 DOES warn too.
Does warn for what? Array with known size? Sure, so it should - you
have excess initializer list elements.
Note the [] in the quoted - it does matter.
Again, it's perfectly legitimate to use string literal to initialize
any kind of array of character type. \0 goes there only if there's
space for it; if array size is unknown, the space is left. That's it.
Sure. Doing 'char c[4] = 01234;' is just like doing '0123': only
those bytes, for which there's space in the array go in, everything makes
perfect sense. What doesn't make sense to me though, is that in the former
case gcc warns, but not in the latter.
Maybe you're right in your interpretation of the standard / KR, but it
doesn't still make it logical to me, sorry. I always thought 0123 was 5
bytes long (ok, ascii) and the terminating '\0' was an integral part of
the string, no different from any other character, and not some optional
token. Thus all the charecters should be handled equally.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Andi Kleen wrote: Guennadi Liakhovetski [EMAIL PROTECTED] writes: char c[4] = 0123; and - a wonder - no warning. 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. 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 Because 5 characters will not fit in a 4 character array, even without the null terminator. 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 -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Andi Kleen wrote: 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. 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 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 is no nice way to make an annotation that says look, I'm going to initialize an array of char with a string literal now, and the resulting array will contain a non-zero member as last element, and I mean it. And since there is no such annotation possible, gcc does not warn and demand that you annotate the perfectly valid and 100% spec-compliant construct char a[4] = 1234;. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: with char c[4] = 012345; the compiler warns, but actually allocates a 6-byte long array... Off-topic here, but: sizeof c / sizeof *c == 4. -- Stefan Richter -=-=-=== =--- ---== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Robert Hancock wrote:
Because 5 characters will not fit in a 4 character array, even without the
null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
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 KR. 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 perfect way to specify a 0123 without the '\0' -
{'0', '1', '2', '3'}.
Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote: On Fri, 3 Aug 2007, Stefan Richter wrote: Guennadi Liakhovetski wrote: with char c[4] = 012345; the compiler warns, but actually allocates a 6-byte long array... Off-topic here, but: sizeof c / sizeof *c == 4. 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. 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, you'd have a cause to complain. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 12:36:40AM +0200, Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Robert Hancock wrote: Because 5 characters will not fit in a 4 character array, even without the null terminator. On Fri, 3 Aug 2007, Stefan Richter wrote: How should gcc know whether you actually wanted that char foo[len] to contain a \0 as last element? 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'. 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 are correct. You are blatantly ignoring the context even when you are including all relevant parts into the quoted text. This stuff hadn't changed since KR. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007 00:36:40 +0200 (CEST) Guennadi Liakhovetski wrote:
On Thu, 2 Aug 2007, Robert Hancock wrote:
Because 5 characters will not fit in a 4 character array, even without the
null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
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 KR. 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 perfect way to specify a 0123 without the '\0' -
{'0', '1', '2', '3'}.
We are actually a bit beyond traditional KR, 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 use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(off-topic) Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
Robert, Stefan, I am sorry, I think, you are VERY wrong here.
You meant to say C99 is very wrong.
And, Stefan, there is a perfect way to specify a 0123 without the '\0' -
{'0', '1', '2', '3'}.
C99 says char c[4] = 0123; is a perfect way to say char c[4] = {'0',
'1', '2', '3'};. Do you want gcc to choose otherwise and ban the former
of the two idioms?
--
Stefan Richter
-=-=-=== =--- ---==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007, Stefan Richter wrote: Guennadi Liakhovetski wrote: with char c[4] = 012345; the compiler warns, but actually allocates a 6-byte long array... Off-topic here, but: sizeof c / sizeof *c == 4. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 03:54:34PM -0700, Randy Dunlap wrote:
And, Stefan, there is a perfect way to specify a 0123 without the '\0' -
{'0', '1', '2', '3'}.
We are actually a bit beyond traditional KR, fwiw.
Not in that area - this behaviour is precisely what traditional KR
had all along. Unchanged.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Randy Dunlap wrote: 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. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On 08/03/2007 01:26 AM, Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: 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. 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... Ah come on, it would be great fun to now make the argument that that quoted bit doesn't actually say wat should happen when there's _no_ room for the terminating null character... Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote: 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. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 3 Aug 2007, Al Viro wrote: It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c) means nasal demon country for you. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Al Viro wrote:
On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote:
On Fri, 3 Aug 2007, Stefan Richter wrote:
Guennadi Liakhovetski wrote:
with
char c[4] = 012345;
the compiler warns, but actually allocates a 6-byte long array...
Off-topic here, but: sizeof c / sizeof *c == 4.
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.
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.
No, the fact that the full 012345\0 ends up in the object file is
apparently unrelated to what happens to the variable c...
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, you'd have
a cause to complain.
...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/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Thu, 2 Aug 2007, Jan Engelhardt wrote:
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
[...]
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...
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.
nitpicking
While we're talking of null-termination of strings, then I bet you
generally want to be using strlcpy(), really. Often strncpy() isn't
what you want. Of course, if that buffer isn't a string at all, then
you should be using memfoo() functions and not strbar() ones in the
first place ...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, Aug 03, 2007 at 08:47:56AM +0530, Satyam Sharma wrote:
On Thu, 2 Aug 2007, Jan Engelhardt wrote:
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
[...]
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...
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.
nitpicking
While we're talking of null-termination of strings, then I bet you
generally want to be using strlcpy(), really. Often strncpy() isn't
what you want. Of course, if that buffer isn't a string at all, then
you should be using memfoo() functions and not strbar() ones in the
first place ...
Afaik, strlcpy() and strlcat() are NOT standard C library functions.
But, I know, they are available in Linux kernel. ;) And yes, they
are better than strn{cpy,cat}().
Regards.
--
_ /|
\'o.O'
=(___)=
U
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
On Thu, 2 Aug 2007, Robert Hancock wrote:
Because 5 characters will not fit in a 4 character array, even without the
null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
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 KR. 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.
Guennadi,
The declaration
char c[4] = abcd;
is perfectly valid.
If other versions of gcc give warnings with that declaration, then those
warnings may be useful but it does not mean to say that other versions of
gcc follow the standards or not.
KR is good as a reference but not as an authority. They drafted the book
as an informal specification of C. C has evolved throughout the decades.
The current standard is C99. And as quoted earlier in this thread,
character array initializations are described as:
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.
The gcc warning you see on other versions is a warning that does not have
anything to do with the current C standard. The other versions of gcc that
do not emit such character initialization warnings do not mean that they
are buggy in that respect.
IOW, the fact that you did not see the warning in a certain gcc version
does not mean that it is buggy in that respect.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: 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. 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... You should not have asked in the first place. The declaration char c[4] = abcd is perfectly valid. There is no cause for debate about it :) Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
