On 04/ 6/12 07:41 PM, Brock Pytlik wrote:
> Changes:
> $ hg diff -r 2652
> diff -r 4c9688c29331 src/zoneproxy/zoneproxy-adm/zoneproxy-adm.c
> --- a/src/zoneproxy/zoneproxy-adm/zoneproxy-adm.c Fri Apr 06 16:06:44 2012
> -0700
> +++ b/src/zoneproxy/zoneproxy-adm/zoneproxy-adm.c Fri Apr 06 19:40:30 2012
> -0700
> @@ -106,5 +106,4 @@
> notify_zoneproxyd(zoneid, remove);
>
> exit(0);
> - return 0;
> }
>
>
> Since it's a one line removal, I thought I'd just do this one in the message.
Looks good to me, as long as it doesn't cause you lint problems for failing to
return an int from a function declared to do so (see explanation in the attached
heads up I sent for this change to the system headers) - and sorry about the
damage.
--
-Alan Coopersmith- [email protected]
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
Subject: HEADS UP: 7118765 changes handling of code past the point of __NORETURN
From: Alan Coopersmith <[email protected]>
Date: 03/14/12 06:49 PM
The putback for CR 7118765 enables for Studio 12.0 and later compilers
the annotations already existing in a number of system headers & ON sources
for providing hints to the compiler about certain functions. These were
added during S10 development to support the gcc compiler used by the AMD64
bringup, but were not available in the Sun Studio compilers at that time.
The annotations now available to both compilers are:
__NORETURN Function will never return (exit(), panic())
__PURE Function will always return the same value for the
same arguments, with no side effects (strlen(), memcmp())
__CONST Function is __PURE, and also does not read from memory either
(ffs(), abs() - though they're not currently marked as such)
__PACKED Structure contents should not be padded for alignment
(similar to #pragma packed)
The __*PRINTFLIKE annotations remain gcc-only due to lack of support in
Studio for that form at this time.
Attempting to wsdiff builds before and after this changeset will show a
large number of differences due to the compiler using this information
for branch prediction, code path analysis, and other possible optimizations.
For developers working on either new integrations to S11U1 or backports to
older releases, this will affect the way you need to handle certain code
constructs in order to avoid lint or compiler warnings.
Previously, if you had a function that was declared with a non-void return
type, lint and cc would warn if you didn't return a value, even if you called
a function like exit() or panic() that ended execution.
For instance:
#include <stdlib.h>
int
callback(int status)
{
if (status == 0)
return status;
exit(status);
}
would previously require a never executed "return 0;" after the exit to
avoid lint warning "function falls off bottom without returning value".
Now the compiler & lint will both issue "statement not reached" warnings for
a "return 0;" after the final exit, allowing (or in some cases, requiring)
it to be removed. However, if there is no return statement anywhere in the
function, lint will warn that you've declared a function returning a value
that never does so, suggesting you can declare it as void. Unfortunately,
if your function signature is required to match a certain form, such as in a
callback, you not be able to do so, and will need to add a /* LINTED */ to
the end of the function, at least unless/until lint CR 7122677 has been
resolved. This putback includes that change to a number of existing source
files in ON to preserve the current level of lint cleanliness.
If you then backport to a older release, especially Solaris 10 or older which
are built with a compiler too old to recognize these attributes, then you will
either have to restore these unreachable statements, or, to keep your sources
common across releases, add to your sources the corresponding #pragma recognized
by both current and older compiler versions, such as:
#pragma does_not_return(exit)
#pragma does_not_return(panic)
--
-Alan Coopersmith- [email protected]
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
