Re: freefuncs.c is never called from anywhere!?]
On Mon, 31 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
I disagree on _deadcode. While the code is rotted, it does implement
some full functions that have no other history, like verion.c for
versioning and xfunc for expensive functions. Yanking them means we can
never know what they did.even 'yanked' code is still in the cvs repository ...
Precisely. Seems to me we ought to think about our code maintenance
methods with knowledge that back versions will be available from CVS.
Keeping stuff in the current tree has some advantages if it's stuff
you think you might want again in the near term, but I think it's
the wrong way to deal with stuff that we're only keeping for historical
purposes. For example, if I wanted to try to understand the xfunc
code, I'd really have to go back to the last version where it worked;
the partially-patched files sitting in _deadcode would most likely be
more confusing than helpful...have to agree here ... how much of the NOT_USED code is totally irrelevant
based on the changes around it?Some sort of 'text log' of what is removed and date should be kept, if ppl
want to be able to go back ... basically, instead of 'moved to _deadcode',
just add a line to a text file stating 'function X removed on date Y' so
that ppl have a guide to look at the cvs repository with ...
I am thinking of going through the code and removing NOT_USED functions
I know to be useless. OK?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Import Notes
Reply to msg id not found: Pine.BSF.4.21.0001312315290.411-100000@thelab.hub.org
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I am thinking of going through the code and removing NOT_USED functions
I know to be useless. OK?
Don't see why not, though I'd recommend treading lightly. That unused-
functions script tends to pull out stuff that has been exported in the
expectation that someone would want it someday, but for one reason or
another it's not being called right at the moment. We don't really want
to delete that sort of code.
BTW, I've also been rather dubious about the automatic
demote-to-static-function script for the same reason --- when someone
comes along and needs function X, it's hard to tell whether X was
intended to be private or was intended to be public but got demoted by
the script. It's tough to maintain clear module APIs with tools like
that second-guessing the author's intentions.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I am thinking of going through the code and removing NOT_USED functions
I know to be useless. OK?Don't see why not, though I'd recommend treading lightly. That unused-
functions script tends to pull out stuff that has been exported in the
expectation that someone would want it someday, but for one reason or
another it's not being called right at the moment. We don't really want
to delete that sort of code.BTW, I've also been rather dubious about the automatic
demote-to-static-function script for the same reason --- when someone
comes along and needs function X, it's hard to tell whether X was
intended to be private or was intended to be public but got demoted by
the script. It's tough to maintain clear module APIs with tools like
that second-guessing the author's intentions.
Well, I put a comment on one's that have to be exported, and others come
up as referenced in the regression tests.
The only one I know about is:
GetAttributeByName
GetAttributeByNum
and some debug functions. The above two are the only ones that I marked
as static at one time that I later had to export.
The other advantage of static is that if a static function is not called
in the file, the compiler throws a warning and I can then mark it as
NOT_USED.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026BTW, I've also been rather dubious about the automatic
demote-to-static-function script for the same reason --- when someone
comes along and needs function X, it's hard to tell whether X was
intended to be private or was intended to be public but got demoted by
the script. It's tough to maintain clear module APIs with tools like
that second-guessing the author's intentions.
Also, I don't touch the interfaces, only the backend code. There aren't
many api stuff there, except spi, which I also don't touch.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
It's tough to maintain clear module APIs with tools like
that second-guessing the author's intentions.
Also, I don't touch the interfaces, only the backend code. There aren't
many api stuff there, except spi, which I also don't touch.
I was talking about intermodule APIs within the backend...
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
It's tough to maintain clear module APIs with tools like
that second-guessing the author's intentions.Also, I don't touch the interfaces, only the backend code. There aren't
many api stuff there, except spi, which I also don't touch.I was talking about intermodule APIs within the backend...
Can you give an example? You mean a function that is meant to be
exported to other modules in the backend, but is not called for some
reason should not be marked as static?
Yes, that is an issue, but reducing our code size and marking functions
static/NOT_USED seems to be a larger benfit. Of course, IMHO.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026