Undefine a function from header file
T Ryi
functions using static in X.c file.
Now i don't want to change the name of loadavg custom functions in
code to loadavg_custom.
But this loadavg is a function defined in stdlib.h. I need other
functions from stdlib.h , so i can't remove the declaration
#include<stdlib.h>
Is there anyway of saying the loadavg in stdlib.h to hide itself ? i
tried doing undef loadavg just after the declaration but it doesn't
work .
Nick Keighley
> i've some old code from 1999. They have implemented their own loadavg
> functions using static in X.c file.
>
> Now i don't want to change the name of loadavg custom functions in
> code to loadavg_custom.
>
> But this loadavg is a function defined in stdlib.h.
your stdlib is broken then
> I need other
> functions from stdlib.h , so i can't remove the declaration
> #include<stdlib.h>
it's a preprocessor directive not a declaration
> Is there anyway of saying the loadavg in stdlib.h to hide itself ?
the short answer is "no", but you might be able to do something nasty
with macros
> i
> tried doing undef loadavg just after the declaration but it doesn't
> work .
there is no "undef" for function declarations. Why don't you use a
different name for your replacement function?
Barry Schwarz
wrote:
It is extremely unlikely that any function is defined in a header.
More likely the function prototype is declared in the header. Unless
you intend to call some of the loadavg functions, the presence of the
declarations in the header should be harmless. If you are rewriting
some of the functions, as long as the signature (return type and
argument types) is the same, the declarations would still be valid.
You need to tell us why the declarations are causing you problems.
stdlib.h is a standard header. loadavg is not a standard library
function. It should not be declared in stdlib.h. If it is, your
compiler should have an option to process only the standard features
of the standard headers. If not, your compiler is not compliant (or
cannot be invoked in a compliant mode) and you will need to raise the
question in a newsgroup that deals with your compiler rather than this
one that deals with the language.
It is possible that "they" (the ones who implemented this back in
1999) modified stdlib.h to include the declaration for loadavg. In
that case, it is permissible to go back in time and terminate them
before they perform this abomination.
One possible method of dealing with such a poor design philosophy
would be:
Scan stdlib.h and identify all the unwanted tokens related to
loadavg.
Build yourself new header (undo_loadavg.h). For each token
identified above, add a #define of the form
#define this_token ____get_rid_of_this_token___
Build yourself a second header (undef_loadavg.h). For each of
the tokens defined out of existence above, add a #undef of the form
#undef this_token
In your code, surround the reference to stdlib.h with
references to the new headers, as in
#include "undo_loadavg.h"
#include <stdlib.h>
#include "undef_loadavg.h"
Now you can add you own loadavg.h header with the declarations
you want.
--
Remove del for email
navin
> On Tue, 23 Mar 2010 23:58:47 -0700 (PDT), T Ryi <tryi...@gmail.com>
> wrote:
>
> Now you can add you own loadavg.h header with the declarations
> you want.
>
declaration but without static.
The source had
#include<stdlib.h>
static int getloadvg.... declaration
int getloadavg(){
...definition1
}
Keith Thompson
[...]
> stdlib.h is a standard header. loadavg is not a standard library
> function. It should not be declared in stdlib.h. If it is, your
> compiler should have an option to process only the standard features
> of the standard headers. If not, your compiler is not compliant (or
> cannot be invoked in a compliant mode) and you will need to raise the
> question in a newsgroup that deals with your compiler rather than this
> one that deals with the language.
According to a later followup, the function in question is actually
getloadavg(), not loadavg().
According to the Linux man page, the synopsis for this function is:
#define _BSD_SOURCE
#include <stdlib.h>
int getloadavg(double loadavg[], int nelem);
Presumably the declaration won't be visible unless the macro
_BSD_SOURCE is defined, so there's no apparent conformance issue.
_BSD_SOURCE might be defined implicitly depending on compiler
options, but it shouldn't be defined in conforming mode.
On Solaris, it's declared in <sys/loadavg.h>.
Still, there's going to be a problem if you want to (a) define
_BSD_SOURCE for access to some other functions, and (b) declare your
own function named "getloadavg()". That's a general problem for
non-standard functions, especially those declared in standard
headers.
It would be easier if all non-C-standard functions were declared in
headers other than the C standard headers, for example in POSIX's
<unistd.h>. The problem is that some of the POSIX-but-not-C functions
predate the C standard. Maintaining both standard conformance and
backward compatibility is messy.
Apparently if you want to use BSD-specific functions, you shouldn't
write your own function called "getloadavg".
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Barry Schwarz
wrote:
If you want to hold a conversation, it helps not to change names.
Kenny McCormack
Barry Schwarz <schw...@dqel.com> wrote:
...
>If you want to hold a conversation, it helps not to change names.
If you (and, presumably most everyone else is equally able) can tell its
the same person, then there's really no problem here, is there?
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...