diff for duplicates of <20090121172837.GA4386@uranus.ravnborg.org> diff --git a/a/1.txt b/N1/1.txt index e22bf59..4a11f60 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,29 +1,25 @@ On Wed, Jan 21, 2009 at 01:13:16PM +0100, Arnd Bergmann wrote: > On Wednesday 21 January 2009, Sam Ravnborg wrote: > > Could we add a new symbol for this? -> > We know we are going to use this in several places so a simpler var= -iant +> > We know we are going to use this in several places so a simpler variant > > would be more readable. -> >=20 +> > > > Something like: -> >=20 +> > > > #ifdef __64BIT > > ... > > #endif -> >=20 -> > When we define __64BIT we would use the =A0__BITS_PER_LONG =3D=3D 6= -4 check. ->=20 -> I would prefer using the __BITS_PER_LONG =3D=3D 64 check directly, be= -cause +> > +> > When we define __64BIT we would use the __BITS_PER_LONG == 64 check. +> +> I would prefer using the __BITS_PER_LONG == 64 check directly, because > it gives you a warning when __BITS_PER_LONG is undefined, whereas the > #ifdef check gets easily fooled by include order problems. Note that > this is not a problem in the kernel for CONFIG_* symbols which are > always defined before the first #include. It gives the warning only if you add -Wundef which IIRC is not default -with -Wall. And using the "__BITS_PER_LONG =3D=3D 64" the risk of gitti= -ng +with -Wall. And using the "__BITS_PER_LONG == 64" the risk of gitting the expression wrong is much higher than the simpler variant where you only write: @@ -32,8 +28,3 @@ you only write: But I have no strong feelings for it. Sam --- -To unsubscribe from this list: send the line "unsubscribe linux-parisc"= - in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 40d9734..f9e5a82 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,29 +19,25 @@ "On Wed, Jan 21, 2009 at 01:13:16PM +0100, Arnd Bergmann wrote:\n" "> On Wednesday 21 January 2009, Sam Ravnborg wrote:\n" "> > Could we add a new symbol for this?\n" - "> > We know we are going to use this in several places so a simpler var=\n" - "iant\n" + "> > We know we are going to use this in several places so a simpler variant\n" "> > would be more readable.\n" - "> >=20\n" + "> > \n" "> > Something like:\n" - "> >=20\n" + "> > \n" "> > #ifdef __64BIT\n" "> > ...\n" "> > #endif\n" - "> >=20\n" - "> > When we define __64BIT we would use the =A0__BITS_PER_LONG =3D=3D 6=\n" - "4 check.\n" - ">=20\n" - "> I would prefer using the __BITS_PER_LONG =3D=3D 64 check directly, be=\n" - "cause\n" + "> > \n" + "> > When we define __64BIT we would use the \302\240__BITS_PER_LONG == 64 check.\n" + "> \n" + "> I would prefer using the __BITS_PER_LONG == 64 check directly, because\n" "> it gives you a warning when __BITS_PER_LONG is undefined, whereas the\n" "> #ifdef check gets easily fooled by include order problems. Note that\n" "> this is not a problem in the kernel for CONFIG_* symbols which are\n" "> always defined before the first #include.\n" "\n" "It gives the warning only if you add -Wundef which IIRC is not default\n" - "with -Wall. And using the \"__BITS_PER_LONG =3D=3D 64\" the risk of gitti=\n" - "ng\n" + "with -Wall. And using the \"__BITS_PER_LONG == 64\" the risk of gitting\n" "the expression wrong is much higher than the simpler variant where\n" "you only write:\n" "\n" @@ -49,11 +45,6 @@ "\n" "But I have no strong feelings for it.\n" "\n" - "\tSam\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-parisc\"=\n" - " in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + "\tSam" -111ccc4c3923a14f86b6d789551309617bf56dea445bf433b97a77e0961370e8 +1f6f595b76d9eaeb7ce9a098655eaa93d33132f146f34e6e859282a8d18f3ea9
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.