🚀 go-pugleaf

Chris Torek wrote:
> 
> In article <4j06iu$7qm@solutions.solon.com> 100576.1776@compuserve.com writes:
> 
[...]
> >#define TRACE(s)                                    \
> >  if (trace_on)                                     \
> >    fprintf(trace_file, __FILE__ __LINE__ "%s", s);
> 
[...]
> 
> OPTION B: convert everything to expressions (use ?: for TRACE):
> 
>         #define CLEAR_ERROR(e) \
>                 ((e).a = (e).b = (e).c = 0, TRACE("clear error"))
>         #define TRACE(s) \
>                 (trace_on ? \
>                  fprintf(trace_file, "%s:%d: %s", __FILE__, __LINE__, s) : 0)
> 
> (I pulled the __FILE__ and __LINE__ expressions apart so that a
> quality compiler can emit a single string constant for __FILE__,
> which could save dozens of Kbytes of text space, depending on how
> you use the macro).
> 

Ok, I must be missing something here. Chris T. is making an "efficiency
improvement" on code that doesn't look to me like it should compile in
the first place. The original code presumes that __LINE__ expands to a
string literal, which it does not. Apparently (and I would be shocked if
this were not the case) Chris T. knows this, as evidenced by the fact
that he used "%d" and not "%s" for the __LINE__ parameter in his fprintf
call. So why didn't he catch and point out such an obvious error? 

Did TC1 decree that integral constant expressions that appear lexically
adjacent to string literals shall be evaluated and stringized in order
to allow subsequent string literal concatenation?

--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com