13 Oct, 2016, Khader wrote in the 1st comment:
Votes: 0
Ok , I have been out of the coding arena for … lets just say a long time.
I have remembered alot but something are stumping me… Maybe because i fixed them and they were easy to fix and they just went to the trash bin in my brain in the past. This one… I am confused on.
I am using Dystopia GOLD, yes I know it is kinda buggy, not as much as I remember it though i guess….
I prefer to not have warnings when I compile, so this is why I am asking.
Problem A)
I goto Compile and i get this…
gcc -c -Wall -g kav_wiz.c
In file included from kav_wiz.c:25:0:
merc.h:5254:7: warning: conflicting types for built-in function ‘logf’
void logf args((char * fmt, …));

#include "merc.h" Is the Line 25 In the kav_wiz

Merch.h as follows for line 5254…. (I INcluded Lines 5239-5259)
/* NOTE: This file only includes two examples! write your own! */

struct slay_type
{
char * owner; /* only this player can use this option */
char * title; /* each one must have a unique title! */
char * char_msg; /* is sent to the "slayer" */
char * vict_msg; /* is sent to the "slayee" (poor sucker)*/
char * room_msg; /* is sent to everyone else in the room */
};

/* I am lazy :) */
#define MSL MAX_STRING_LENGTH
#define MIL MAX_INPUT_LENGTH

void logf args((char * fmt, …)); <—This is Line 5254

void copyover_recover args((void));


#endif


So maybe just maybe there is a way to fix this? Cause when a make clean and do it, it does it alot more than just the things I do edit.
13 Oct, 2016, Pymeus wrote in the 2nd comment:
Votes: 0
Assuming you DON'T want to go through all of the code and change logf()'s name everywhere it occurs, try adding the -fno-builtin-logf switch to the compile commands (via CFLAGS, for example).
13 Oct, 2016, Khader wrote in the 3rd comment:
Votes: 0
You assume right…. but doesn't the -fno-builtin-logf just mute logf seen by the compiled portion so I dont see it anymore?
Personally I would rather have it fixed than just muted when compiled.

The Thing is … If anything I could just use the 'replace all' feature so replace all the logf lines, with the fixed line,
I dont mind fixing it as long as it stays fixed, and it actually does fix the problem….
Do you have any solutions on how to fix it replace that line with what exactly? Or what to replace the logf with? IDR there being anything… but then that was a while ago.
13 Oct, 2016, Pymeus wrote in the 4th comment:
Votes: 0
Untrue, -fno-builtin-logf tells the compiler not to use its built in optimized replacement for logf() at all. The warning goes away because the compiler no longer has conflicting declarations of logf() (unless you've #included such a definition from, say, math.h). A suppressed warning option looks like -Wno-unused-parameter, and there doesn't appear to be a -Wno-XXX for suppressing the warning you're seeing.

If you're renaming the function, it doesn't really matter what you rename it to as long as (1) no other function or keyword is using that name, and (2) you rename it consistently across all source files. I like identifiers that are reasonably unambiguous, so maybe log_printf? Whatever you like.

EDIT: I think I see now what you're saying. You don't have to replace your code's logf with another function. When you do a search-and-replace of "logf" with a new function name (ie log_printf), you'll end up replacing the declaration and definition of the function as well. You keep all of the functionality, just under a new name.
14 Oct, 2016, Khader wrote in the 5th comment:
Votes: 0
Ahhh ok… that makes sense then…
Although now that you mention the "Wno-unused-parameter"…I did get alot of these on the initial compile though…
[-Wformat-security]
[-Wunused-but-set-variable]
[-Wmaybe-uninitialized]
[-Waddress]
[-Wpointer-sign]
[-Wparentheses]

It will very from file to file on what it appears on, it compiles ok, I don't get any crashes, run fine as well….but then, they are all warnings, not errors, which I just wanted a clean compile, I don't remember when I did this a long time ago these warnings popping up. I remember a clean compile of everything when I did it 10+ years ago. Unless My mind is totally fried from the Arizona heat that I am remembering something different.
14 Oct, 2016, quixadhal wrote in the 6th comment:
Votes: 0
A better solution is to go look at your local logf() function (if you even have one) and see if it's anything unusual. It's almost ALWAYS a better idea to use the system's built-in version, since it will be optimized, and may even have been written in assembly for your processor.

So, instead of turning off built-in functions, stop using the kludge versions if you can. :)
14 Oct, 2016, Rhien wrote in the 7th comment:
Votes: 0
If you do want to rename it, global find and replace should work pretty well in this case. If you're not using Git or a source control, I recommend it. It makes undoing anything easy (as well as being able to get and push to your sources from anywhere which opens up the tools you can use easily).

I run my development mud on Linux where I do most of the coding but I also have it compiling in Windows with Visual Studio 2015 (I use community edition which is free). It's nice right clicking on a function name, renaming it and having it update all references on the spot. Push it to git, pull it back down on the Linux box, done in a few minutes.
15 Oct, 2016, Pymeus wrote in the 8th comment:
Votes: 0
quixadhal said:
A better solution is to go look at your local logf() function (if you even have one) and see if it's anything unusual. It's almost ALWAYS a better idea to use the system's built-in version, since it will be optimized, and may even have been written in assembly for your processor.

So, instead of turning off built-in functions, stop using the kludge versions if you can. :)

merc's logf() is for writing formatted strings to a log file, where the builtin logf() gets the natural logarithm of a float, so I'm going to have to disagree with you in this particular case.
15 Oct, 2016, Tijer wrote in the 9th comment:
Votes: 0
just change the logf function to log_f and then do a find and replace on all of the calls to that function will generally fix it :)
0.0/9