On 1/18/2010 4:42 PM, Tom Lane wrote:
I think including MSVC in the set of compilers targeted by a configure
test is just a waste of code. It's more likely to confuse people than
help them.
Ok, I have taken that out, and instead put the right stuff for MSVC into
pg_config.h.win32.
Regards,
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident
On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
We have some existing inline functions in .c files. These can be
more complicated, so it might be ok if the compiler decides to
leave them out
On 12/16/2009 8:40 AM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com writes:
IIRC Kurt was also on about getting rid of some ugly macros that could
instead be coded as inline functions (fastgetattr for example)
I'd just bounce that as useless activity. If they are macros now,
and
On 12/16/2009 8:21 AM, Tom Lane wrote:
I would only suggest that the cleanest coding would be
#ifdef USE_INLINE
static inline foo(...) ...
#else
... non-inline definition of foo
#endif
ie, go ahead and rely on autoconf's definition (if any) of inline
On 2/10/2010 7:12 AM, Tom Lane wrote:
Kurt, you seem to be more or less impervious to advice :-(.
Thank you for reviewing my patch. It is a rare honor to
have my personal qualities reviewed here as well.
Since this forum is archived for posterity, I suppose I
must point out that I have in
On 1/17/2010 11:27 AM, Peter Eisentraut wrote:
I have found an Autoconf macro that checks whether the compiler properly
supports C99 inline semantics. This would allow us to replace the
__GNUC__ conditional with HAVE_C99_INLINE, in this case.
At present, PostgreSQL uses only static inline,
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident
On 1/19/2010 8:43 AM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
Or compiler switches could be set to disable all such warnings
globally. Warning 4514 is specific to inline functions; so
maybe it would be alright to keep
On 1/18/2010 1:20 PM, Peter Eisentraut wrote:
I seem to recall that somewhere else it was said that MSVC produces
warnings on unused static inline functions. Am I mistaken?
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of
On 1/18/2010 4:42 PM, Tom Lane wrote:
Kurt Harrimanharri...@acm.org writes:
c) Use configure to automate the testing of each build environment
in situ.
The third alternative adapts to new or little-known platforms
with little or no manual intervention.
This argument is bogus
On 12/16/2009 7:10 AM, Tom Lane wrote:
the project policy is to not require any compiler features not found
in C89.
Is there somewhere a compendium of such policies which
fledgling hackers should consult to avoid embarrassment?
Regards,
... kurt
--
Sent via pgsql-hackers mailing list
On 12/15/2009 4:05 AM, Marko Kreen wrote:
On 12/15/09, Kurt Harrimanharri...@acm.org wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the submitted branch:
On 12/15/2009 1:31 PM, Marko Kreen wrote:
Do you have actual proof that MSVC launches warnings on unused
static inline functions? Not static, but static inline.
Yes, I tried it, and that's why I did it this way.
If yes, indeed we need to fix it. MSVC is broken then, but it does
not matter
On 12/15/2009 2:09 PM, Marko Kreen wrote:
Oh. Ok then. Force-inline seems better fix as we may want to use
it for other reasons too (converting big macros).
So it seems like a good moment to solve it for gcc too.
Is ordinary inlining not sufficient?
If deluxe inlining is something that
[Please ignore the previous incomplete version of this reply, which I
sent by mistake. Sorry for the list noise.]
On 12/15/2009 2:09 PM, Marko Kreen wrote:
Oh. Ok then. Force-inline seems better fix as we may want to use
it for other reasons too (converting big macros).
So it seems like
On 12/15/2009 9:42 PM, Robert Haas wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harrimanharri...@acm.org wrote:
Your worry ii) can be ignored, managing to compile on such
compilers is already overachievement.
I think so too. With your opinion added to mine, do we constitute a
consensus of
Tom Lane wrote:
Kurt Harriman harri...@acm.org writes:
(Does anybody still use a C compiler that doesn't support
inline functions?)
The question isn't so much that, it's whether the compiler supports
inline functions with the same behavior as gcc.
With this patch, if the compiler doesn't
Bruce Momjian wrote:
Peter Eisentraut wrote:
On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
I thought one problem was that inline is a suggestion that the compiler
can ignore, while macros have to be implemented as specified.
Sure, but one could argue that a compiler that doesn't
changed, 18 insertions(+), 17 deletions(-)
--- Kurt Harriman harri...@acm.org 2009-11-29 08:22:05 -0800
diff --git a/configure.in b/configure.in
index 612e843..467f40d 100644
--- a/configure.in
+++ b/configure.in
@@ -1105,6 +1105,10 @@ PGAC_STRUCT_SOCKADDR_STORAGE
Tom Lane wrote:
Kurt Harriman harri...@acm.org writes:
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
There is no such option, and won't be.
Yours is the first comment anyone has posted
Is there anything in the source that would necessarily preclude using the
C++ compiler to build *all* the code?
No. Most of the source files would need a sprinkling of
tiny changes: typically only a handful of casts need to be
added. Some files would need more widespread (but still
trivial)
Tom Lane wrote:
if we fix some or all of the headers, what's the
plan for making sure that they stay fixed? Without a C++ buildfarm
member I think the chances of future breakage approach certainty.
Actually, after re-reading the whole earlier thread I see that we did
think of a possible
Hi Greg,
Actually I did email this to the list with 4 separate diffs in
4 separate attached files. I don't know why it appears all
massed together at http://archives.postgresql.org/pgsql-hackers.
I'll try resubmitting them separately. The first diff consists
of just the renaming, which is
(Re-sending just the first of four patches: c++reserved)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
1. c++reserved
User-defined functions and
(Re-sending just the second of four patches: c++bookends)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
2. c++bookends
C++ code can call C functions
(Re-sending just the third of four patches: c++configure)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
3. c++configure
This patch adds C++ support to
(Re-sending just the fourth of four patches: c++exception)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
4. c++exception
When C code calls C++ code,
/ etc - notably, PostgreSQL's own tree structures and
data types.
Thanks for your comments; I hope I've responded adequately.
In any case, I welcome further dialogue on these or other topics.
Regards,
... kurt
Peter Eisentraut wrote:
Kurt Harriman wrote:
Sometimes people would like to call C
Peter Eisentraut wrote:
FYI, we have received patches morally equivalent to yours many times
over the years, and they have all been rejected. You might want to
review the archives about that.
Hi Peter,
I went back as far as 2005 in the archives, and found only this thread
covering similar
Tom Lane wrote:
Kurt Harriman [EMAIL PROTECTED] writes:
[ make the backend C++-compilable ]
This has been proposed before, and rejected before, and I don't believe
the arguments have changed in the least.
Hi Tom,
Of the series of four patches, the first two (c++reserved and c++bookends
Hi,
Brendan Jurd submitted a patch to add a pg_typeof() builtin function:
http://archives.postgresql.org/pgsql-patches/2008-09/msg00029.php
I've reviewed the patch and it looks fine. An updated version is
attached, having made these changes:
1) Rebased to current CVS head
2) func.sgml:
Just noticed buffile.c:292 doesn't look quite right where
BufFileDumpBuffer calls FileWrite:
bytestowrite = FileWrite(thisfile, file-buffer, bytestowrite);
It looks as though it would write the same data each time the
loop is iterated. Would this be better?
bytestowrite =
33 matches
Mail list logo
