This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2 v4] libc-internal.h: add ALIGN helper macros


On 06/19/2013 11:07 AM, Mike Frysinger wrote:
> On Wednesday 05 June 2013 08:15:12 Rasmus Villemoes wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>>> On Tuesday 04 June 2013 06:49:00 Rasmus Villemoes wrote:
>>>> I'm afraid one would have to deal with types anyway, as recently seen
>>>> in the kernel http://lwn.net/Articles/548336/.
>>>
>>> this is easily solved in the macro form:
>>> 	#define ALIGN_DOWN(base, size) ((base) & ~((__typeof__(base))(size) -
>>> 	1))
>>>
>>> which isn't easily achievable with inline funcs
>>
>> (I wasn't trying to argue for inline funcs.)
>>
>> Yes, this seems to work. At first I thought one would have the
>> opposite problem when typeof(base) was narrower than typeof(size) in
>> the case of ALIGN_UP. But in that case the __typeof__ is actually
>> applied to ((base)+(size)-1), which is of course sufficiently wide.
>>
>> Is the extra expansion of size in ALIGN_UP a problem?
> 
> if someone passes a value with side effects, then yes.  that seems a bit 
> unusual for these types of funcs (doing something like aligning to val++).  i 
> don't see a way past it short of not providing the macro.

Add a comment specifically calling out that there should be no side-effects
to the arguments? I'd be happy at that. The atomic macros have the same problem
and we live with it. Everyone knows they shouldn't be doing things like that
with macros.

c.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]