linux-kernel - Re: [Tux3] Tux3 report: Tux3 Git tree available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200903142036.50335.phillips@phunq.net>
Date:	Sat, 14 Mar 2009 20:36:50 -0700
From:	Daniel Phillips <phillips@...nq.net>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, tux3@...3.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Tux3] Tux3 report: Tux3 Git tree available

On Thursday 12 March 2009, OGAWA Hirofumi wrote:
> Daniel Phillips <phillips@...nq.net> writes:
> >> > > - What's "L"?
> >> > > 
> >> > > 		printf("%Lx-", (L)begin);
> >> > 
> >> > A very handy way of working around 32/64 bit format string issues.  We
> >> > just cast all the messy cases to (long long), aka (L).  All other
> >> > solutions to this messy problem are worse in my opinion, but whatever
> >> > the ruling is, is what we will do.  This is used heavily in tracing and
> >> > dumping code, which can all be turned off with ifdefs, so it doesn't
> >> > affect production kernel text.
> >> 
> >> What format string issues are we talking about here?
> >> 
> >> See, a number of them will be fixed real soon now (geologically
> >> speaking) when various 64-bit architectures switch their s64/u64
> >> implementation from `long' to `long long'.
> >
> > Ah, that would be helpful.  But not done yet?  How long until it
> > happens, and does it make sense to wait, so we can reduce the number
> > of problems cases?  And... will it be all 64 bit arches or just some?
> > Because this issue isn't solved if it isn't fixed for all arches.
> >
> > There are a couple of issues, one is u64 being (long) instead of
> > (long long) as you say, and the other is variable type sizes like
> > loff_t.  That specific one isn't actually a problem, we can just refuse
> > to support 32 bit libc file ops, but there may be others.  We had a
> > world of pain before (L) arrived, then with (L) it was easy.  Maybe
> > just edit them all to (long long) for now, and damn the line length.
> 
> BTW, those are almost because of userland issue. Kernel are more and
> more using same type. But, glibc is not. And we (tux3) are sharing the
> same code with kernel and userland. Some types are depending to
> CONFIG_*, so if we have generic cast type like (L).
> 
> [The fatfs also has own type (llu), if it become generic, fatfs will
> also be happy.]
> 
> Thanks.

Maybe we should argue for some generic flavor of the (L)/(llu) idea
then.  I suppose we should figure out exactly how much of our usage
will remain after the kernel issue is resolved.  One small thing we
could do is make it a typedef instead of a macro.  And spelling it
out completely as (long long) is not so bad, except it loses the
desirable property of being able to grep for the messy thing, and
adds a painful amount of useless line length, given how frequently
the issue shows up.

Regards,

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/