Do any of the compilers we care about not support __func__ or __FUNCTION__?

Andrew Bartlett abartlet at
Thu Jul 19 16:09:10 MDT 2012

On Thu, 2012-07-19 at 23:19 +0200, Christian Ambach wrote:
> On 07/19/2012 08:13 PM, Richard Sharpe wrote:
> >>> I am sick of seeing things like:
> >>>
> >>>                                  DEBUG(5,("read_fd_with_timeout: "
> >>>                                          "blocking read. EOF from client.\n"));
> >>>                                  return NT_STATUS_END_OF_FILE;
> >>>
> >>> where the name of the calling function has been laboriously typed in
> >>> ... and there have been cases where code has been moved around and the
> >>> function name not corrected.
> >>
> >> I totally agree. It's redundant information with the __func__ prefix
> >> added by DEBUG, and is often incorrect.
> >
> > Actually, David, thanks for explaining what I was really complaining about.
> >
> > Yeah, since DEBUG puts the __func__prefix in the log, we don't need to
> > repeat the function name. It just clutters things up.
> >
> Maybe we should then streamline the logging to stderr to also include
> __func__, as that one only prints out the blank message and not the
> function name.
> When looking at outputs of e.g. smbstatus -d 5 or smbclient -d 10 -L
> //localhost you'll see lots of lines that you cannot tell where those
> are coming from. Some lines have the manually added function name that
> helps finding that particular message in the source. So those have their
> use until the output gets changed.

The missing log header on stderr was due (I think) to us using DEBUG()
as a user-interactive message printer earlier.  We have of course moved
on, and if we want our users to see a message, then converting it via
our message catalog with _() and using d_printf() is the right thing to

Always printing the header would also make the debug code simpler, which
would be a good thing.

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list