On 08/16/10 12:49 AM, Darren Kenny wrote:
On 08/ 6/10 05:39 PM, Keith Mitchell wrote:
On 08/ 6/10 02:03 AM, Darren Kenny wrote:
On 08/ 5/10 08:13 PM, Evan Layton wrote:
On 7/16/10 8:17 AM, Darren Kenny wrote:
install_logging.c
------------------
<...snip...>
- Each function seems to have it's own "function" local
variable which is the name of the function being run at the time.
This shouldn't be needed - the compiler already has such a value
which is the macro __func__ if the compiler flag
'-features=extensions' is specified - unfortunately it's not, maybe
this is something to ask RE/Gatekeepers about since it would be more
reliable than defining a local variable all the time in code. If
you don't go this route, the variable should probably be defined as
static and const too to avoid creating it each time a function is
called.
- _report_error(), log_message() and report_progress()
Hi Darren,
Ginnie and I were talking about this and we're not comfortable at all
with the idea of being dependent on "make" to determine the name of
the function. We're passing that function name as a string into the
error simply to have record of where in the code we hit a failure
and being dependent on make to come up with that name seems
overcomplicated and possibly error prone. Why would we want to
depend on make for this when the code already has that name?
Hi Evan / Ginnie,
This is something that is highly used in GNOME/GTK code where macros are written
to output errors, which use the __func__[1] symbol - and because the compiler
generates this static variable it allows for people to write things like:
log_error("message")
which would map to something like:
#define log_error(x) real_logger("%s: %s\n", __func__, (x))
so this means you will always get the function name output, and the consumer of
the API never needs to think of it, it just works.
I feel that rather than each method having a declaration like:
int
my_func(...)
{
...
static const char* function = "my_func";
...
}
it just makes sense to use the __func__ variable when the compiler is able to
give it for minimal cost (I'm reckoning it's not free, since it's an extra bit
of code generated - but I'd imagine not much more than the above).
Maybe it's not acceptable by RE/gatekeepers to not include the
"features=extensions" flag to the compiler - but I feel that's a decision for
RE/gatekeepers and it should be documented as to why not to include it.
Thanks,
Darren.
[1] - http://docs.sun.com/app/docs/doc/819-5267/bkaeo?l=en&a=view
Just to clarify, __func__ is a c99 standard, and is supported by Sun
Studio 12 and gcc:
http://docs.sun.com/app/docs/doc/819-5265/bjayy?a=view#bjaze
http://gcc.gnu.org/c99status.html
Darren, your link above is from a C++ user's guide, so the
"-features=extensions" is actually not applicable in our case.
My mistake on the C++ side...
So on the C side, is there any chance of using the -xc99 c-compiler flag for the
build?
Thanks,
Darren.
Looks like it's already being done on a case-by-case basis - see
libaiscf_pymod/Makefile and libtarget_pymod/Makefile. There are
Makefiles in ON that also enable C99 syntax, so I don't see any present
or future problems with using __func__.
- Keith
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
