mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1
Date: Sun, 23 Nov 2014 11:37:19 -0500	[thread overview]
Message-ID: <20141123163719.GK29621@brightrain.aerifal.cx> (raw)
In-Reply-To: <1416759497.16006.457.camel@eris.loria.fr>

On Sun, Nov 23, 2014 at 05:18:17PM +0100, Jens Gustedt wrote:
> > > > > > > What has all of this to do with VLA? I am lost.
> > > > > > 
> > > > > > The operands of __typeof__ and sizeof get evaluated when they have VLA
> > > > > > type. I think this is the problem.
> > > > > 
> > > > > ah, ok
> > > > > 
> > > > > No, this isn't a problem, I think. Arrays aren't allowed to be subject
> > > > > of an _Atomic qualification (arrays are never qualified
> > > > > themselves). For _Atomic type, the standard explicitly excludes
> > > > > arrays. So arrays in general and VLA in particular should never be
> > > > > passed as such into any of these generic functions, only pointers to
> > > > > atomic objects can.
> > > > 
> > > > Is a pointer to a variably modified type considered variably modified?
> > > 
> > > yes
> > > 
> > > > If so maybe these are affected too...
> > > 
> > > no, the pointers that can be passed to the atomic "functions" are
> > > always pointers to atomic objects, so they can't be arrays (and so
> > > VLA) themselves, nor can an atomic struct containt a VLA or a pointer
> > > to VLA.
> > 
> > _Atomic int (*pmat)[n];
> > 
> > Then &pmat is a pointer to a valid atomic type, an atomic pointer to a
> > VLA type.
> 
> I don't see that. Ain't that a pointer to a VLA of base type _Atomic
> int?
> 
> The beast that you describe would be
> 
> int (*_Atomic pmat)[n];

Yes, I messed it up. Sorry.

> and effectively this would be an atomic pointer to VM type. But
> concerning size, atomicity etc this is just a pointer type like any
> other. (The size information doesn't change, once it is initialized.)
> And concerning the atomic functions this is not different to
> 
> int (*_Atomic pmat)[];
> 
> Could you describe a bit more, where you think that there is a problem
> with such a thing?

But it's a variably-modified type, so sizeof and typeof evaluate the
expression when their operand is of this type. Thus, all you have to
do is make an array of objects of this type, and then refer to
arr[i++]. This will be an expression with variably-modified type, and
the evaluation will have unwanted side effects.

Rich


  reply	other threads:[~2014-11-23 16:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-09 12:53 Joakim Sindholt
2014-11-09 17:11 ` Jens Gustedt
2014-11-22 20:52   ` Joakim Sindholt
2014-11-22 23:09     ` Jens Gustedt
2014-11-22 23:30       ` Rich Felker
2014-11-23  1:31         ` Jens Gustedt
2014-11-23  1:43           ` Rich Felker
2014-11-23  1:47             ` Joakim Sindholt
2014-11-23  2:42               ` Rich Felker
2014-11-23  9:43               ` Jens Gustedt
2014-11-23 15:21                 ` Rich Felker
2014-11-23 16:29                   ` Jens Gustedt
2014-11-23 16:38                     ` Rich Felker
2014-11-23 17:05                       ` Jens Gustedt
2014-11-23 17:29                         ` stephen Turner
2014-11-23 19:38                         ` Rich Felker
2014-11-23  8:49             ` Jens Gustedt
2014-11-23 15:06               ` Rich Felker
2014-11-23 16:18                 ` Jens Gustedt
2014-11-23 16:37                   ` Rich Felker [this message]
2014-11-23 18:01                     ` Jens Gustedt
2014-11-23 19:39                       ` Rich Felker
2014-11-23 23:30                         ` Jens Gustedt

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=20141123163719.GK29621@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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).