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