-ansi in Makefile and snprintf() about libutp

[ghazel]

snprintf should be available in C89... There are no C99 features used in the implementation. What error message are you getting?

[rb07]

-ansi is not equivalent to C89 but to C90, the later doesn't define snprintf() and that causes the problem.

Ref: http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options

What error message are you getting?

Building Transmission (2.30 or 2.31 which are the releases using libutp) on Cygwin with the usual configure :

Making all in libutp
CXX utp.o
In file included from utp.cpp:78:
utp_config.h:8:2: warning: #warning implement this in libtransmission
utp.cpp: In member function 'const char* PackedSockAddr::fmt(char*, size_t) const':
utp.cpp:190: error: 'snprintf' was not declared in this scope

And this is not a question about how to build, or what is on is not on the standards, I already researched that, and I already build Transmission, I just wanted to report this issue.

[ghazel]

Does using -std=c89 instead of -ansi solve the compilation problem?

[rb07]

Yes and no, just by not using -ansi the compilation succeeds, if you use -std=c89 or c99 the output has a warning:

cc1plus: warning: command line option "-std=c89" is valid for C/ObjC but not for C++

which of course can be ignored, just tells you should know your tools better ;-)

[ghazel]

Then -ansi means more than just -std=c90, or it would print the same warning, right?

[rb07]

No.

-std=c90 ? That one doesn't exist when using g++, i.e. no warning, you get an error: unrecognized command line option "-std=c90".

The reference I gave above says "-ansi In C mode, this is equivalent to -std=c90'. In C++ mode, it is equivalent to-std=c++98'."

So if you use -std=c++98 you get the same error ('snprintf' was not declared in this scope) as with -ansi.

[ghazel]

So it looks like the only way to get snprintf is to leave off -ansi or specifically use -std=gnu++98 (which is the default). That's odd. I suppose the Microsoft dialect also added snprintf on top of c++98.

Anyway, I'll just remove the uses of -ansi, it was leftover from trying to enforce C89 with C code.

[rb07]

Just for documentation:

• no -ansi (equivalent to -std=gnu++98), builds fine.
• -std=gnu++0x, also builds fine.
• -std=c++0x, fails.

and it all comes to the strictness of the header (stdio.h), the one in Cygwin happens to be very strict, I guess just about anywhere else (I've built the same on 2 different Linux with no change required) didn't go that far.