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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
