All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexander van Heukelum" <heukelum@fastmail.fm>
To: "Al Viro" <viro@ftp.linux.org.uk>,
	"Guennadi Liakhovetski" <g.liakhovetski@gmx.de>
Cc: "Stefan Richter" <stefanr@s5r6.in-berlin.de>,
	"Andi Kleen" <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org
Subject: Re: gcc fixed size char array initialization bug - known?
Date: Fri, 03 Aug 2007 16:04:10 +0200	[thread overview]
Message-ID: <1186149850.31083.1203581997@webmail.messagingengine.com> (raw)
In-Reply-To: <20070802230914.GT21089@ftp.linux.org.uk>


On Fri, 3 Aug 2007 00:09:15 +0100, "Al Viro" <viro@ftp.linux.org.uk>
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
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - Choose from over 50 domains or use your own


  parent reply	other threads:[~2007-08-03 14:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-02 19:55 gcc fixed size char array initialization bug - known? Guennadi Liakhovetski
2007-08-02 19:59 ` Jan Engelhardt
2007-08-02 20:03   ` Jesper Juhl
2007-08-02 20:10     ` Al Viro
2007-08-02 20:12       ` Jesper Juhl
2007-08-02 20:15     ` Guennadi Liakhovetski
2007-08-03  3:17   ` Satyam Sharma
2007-08-03  3:40     ` WANG Cong
2007-08-03  7:32       ` Bernd Petrovitsch
2007-08-02 20:08 ` Al Viro
2007-08-02 20:21   ` Guennadi Liakhovetski
2007-08-02 20:26   ` Guennadi Liakhovetski
2007-08-02 21:09     ` Al Viro
2007-08-02 21:26       ` Guennadi Liakhovetski
2007-08-02 20:18 ` Jan Engelhardt
2007-08-02 21:06 ` Andi Kleen
2007-08-02 20:36   ` Guennadi Liakhovetski
2007-08-02 22:15     ` Stefan Richter
2007-08-02 22:36       ` Guennadi Liakhovetski
2007-08-02 22:42         ` (off-topic) " Stefan Richter
2007-08-02 22:54         ` Randy Dunlap
2007-08-02 23:03           ` Al Viro
2007-08-02 23:26           ` Guennadi Liakhovetski
2007-08-02 23:34             ` Rene Herman
2007-08-03  5:00             ` Carlo Florendo
2007-08-02 23:02         ` Al Viro
2007-08-03  4:57         ` Carlo Florendo
2007-08-02 22:31     ` Stefan Richter
2007-08-02 22:51       ` Guennadi Liakhovetski
2007-08-02 23:09         ` Al Viro
2007-08-02 23:27           ` Stefan Richter
2007-08-02 23:30           ` Guennadi Liakhovetski
2007-08-03  7:56             ` Jan Engelhardt
2007-08-03 14:04           ` Alexander van Heukelum [this message]
2007-08-02 23:42 ` Jakub Jelinek
2007-08-03 15:16   ` Stefan Richter
     [not found] <fa.LxMYkBaN628VuktB9CFi9SC3LTA@ifi.uio.no>
     [not found] ` <fa.6wYNfcIjXc+jXzdUGE5gFFOal1g@ifi.uio.no>
     [not found]   ` <fa.cjPWb5ZShF43DhggNXkMKMadPYY@ifi.uio.no>
2007-08-02 21:42     ` Robert Hancock

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=1186149850.31083.1203581997@webmail.messagingengine.com \
    --to=heukelum@fastmail.fm \
    --cc=andi@firstfloor.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

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

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