Re: [lwip-users] Print Macros

[David Empson]

Robert Laughlin wrote:
> My compiler tries to process the format string at compile time, so that
> the application will run faster
> during execution. That is the reason it fails with the macros as coded
> now. It apparently does that
> scan before concatenating the string.

That is defintiely not compatible with ANSI C. String concatenation is
supposed to take place well before any code optimization.

Is there a compiler option to turn off that behaviour?

>  So how about this:
>
> Code the macros like this:
>
>
> #define U16_F  "%u"
>
> Then the invocation would look like this:
>
>
> LWIP_DEBUG(TCP_DEBUG,("tcb_bind: bind to part "U16_F"\n, port));
>
> The change here is that the % sign is part of the substitution rather than
> before.  The only disadvantage
> I think is that there are a few cases in the code where a "length" of the
> field is specified, and those
> would need their own macros.

I found 79 lines which included such cases (one of which looks to be a
typo, for which I've submitted a bug report). I used a Perl-compatible grep 
with the regular expression

%[^%"]+".{1,4}_F

(Percent, one or more non-percent and non-double-quote, double quote, 1 to 4
characters then "_F".)

(Standard grep would work as well, if the ".{1,4}" is replaced with "...",
assuming all these macros have three characters before the "_F".)

The resuls included %02, %04, %08, %2, %5, %3, %4, %010, with various
combinations of the string macros (U16_F, X16_F and others).

I doubt that your compiler would handle a macro with a parmeter, as that
would require stringifying the parameter and concatenating strings.
Therefore a separate macro would be needed for every variant, and for any
new variant which someone might need in future.

I don't think this is reasonable, since it would create more work on an 
ongoing basis.


I would also like to note that LWIP's current macro usage is consistent with
established conventions such as C99's inttypes.h.