netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mitchell Blank Jr <mitch@sfgoth.com>
To: Erik Mouw <erik@harddisk-recovery.com>
Cc: Stephen Hemminger <shemminger@osdl.org>,
	bcm43xx-dev@lists.berlios.de, netdev@vger.kernel.org,
	torvalds@osdl.org
Subject: Re: [PATCH] bcm43xx: iw_priv_args names should be <16 characters
Date: Fri, 14 Apr 2006 03:33:21 -0700	[thread overview]
Message-ID: <20060414103321.GD26289@gaz.sfgoth.com> (raw)
In-Reply-To: <20060414093503.GF20839@harddisk-recovery.com>

Erik Mouw wrote:
> On Thu, Apr 13, 2006 at 10:29:19AM -0700, Stephen Hemminger wrote:
> > Shouldn't compiler have gagged on this?
> 
> Apparently not. At least the compiler I use doesn't warn about it (gcc
> version 3.3.5 (Debian 1:3.3.5-13)).
> 
> Linus, this might be be something for sparse to check:
> 
>   struct mystruct {
> 	char name[16];
>   };
> 
>   mystruct ms = { .name = "muchlongerthan16characters" };

If you actually try that example you'd see that gcc (even really old
versions) will warn you about that code.

What gcc WON'T warn about is if everything but the final '\0' fits in
the array.

So the code:
	struct mystruct { char name[16]; };
	struct mystruct exact_length = { .name = "0123456789abcdef" };
	struct mystruct one_too_long = { .name = "0123456789abcdefg" };

Produces:
	a.c:3: warning: initializer-string for array of chars is too long
	a.c:3: warning: (near initialization for 'one_too_long.name')

I believe this is intentional and in line with the C specs.  It's also
useful since it allows you to define macros like:

	#define DECLARE_NON_TERMINATED_STRING(name, val) \
			const name[sizeof(val "") - 1] = val;

Making sparse a bit stricter than gcc in this case might not be a bad idea,
though.

-Mitch

      reply	other threads:[~2006-04-14 10:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13 13:02 [PATCH] bcm43xx: iw_priv_args names should be <16 characters Erik Mouw
2006-04-13 17:29 ` Stephen Hemminger
2006-04-14  9:35   ` Erik Mouw
2006-04-14 10:33     ` Mitchell Blank Jr [this message]

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=20060414103321.GD26289@gaz.sfgoth.com \
    --to=mitch@sfgoth.com \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=erik@harddisk-recovery.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.org \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).