Re: [pgsql-patches] Getting rid of warnings

2007-01-26 Thread Magnus Hagander
On Thu, Jan 25, 2007 at 08:56:27PM +0100, Magnus Hagander wrote:
 Bruce Momjian wrote:
  I need an updated version of this to apply.  The suggested changes are
  too extensive.
 
 
 I'll try to do this tomorrow. If I get it right, the changes needed are:
 NULL instead of cast of function ptr, per Peter.
 Do the const-change in the other direction in contrib/intarray.
 
 The patch never contained anything for those const ** warnings, so I'll
 just continue not to include those.
 

Ok, here's an updated patch per this.

//Magnus

Index: contrib/intarray/_int.h
===
RCS file: /projects/cvsroot/pgsql/contrib/intarray/_int.h,v
retrieving revision 1.11
diff -c -r1.11 _int.h
*** contrib/intarray/_int.h 4 Oct 2006 00:29:45 -   1.11
--- contrib/intarray/_int.h 26 Jan 2007 11:48:20 -
***
*** 108,114 
  /*
  ** useful function
  */
! bool  isort(int4 *a, const int len);
  ArrayType  *new_intArrayType(int num);
  ArrayType  *copy_intArrayType(ArrayType *a);
  ArrayType  *resize_intArrayType(ArrayType *a, int num);
--- 108,114 
  /*
  ** useful function
  */
! bool  isort(int4 *a, int len);
  ArrayType  *new_intArrayType(int num);
  ArrayType  *copy_intArrayType(ArrayType *a);
  ArrayType  *resize_intArrayType(ArrayType *a, int num);
Index: contrib/pg_trgm/trgm_op.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pg_trgm/trgm_op.c,v
retrieving revision 1.5
diff -c -r1.5 trgm_op.c
*** contrib/pg_trgm/trgm_op.c   30 May 2006 22:12:13 -  1.5
--- contrib/pg_trgm/trgm_op.c   25 Jan 2007 12:18:05 -
***
*** 5,11 
  
  PG_MODULE_MAGIC;
  
! float4trgm_limit = 0.3;
  
  PG_FUNCTION_INFO_V1(set_limit);
  Datum set_limit(PG_FUNCTION_ARGS);
--- 5,11 
  
  PG_MODULE_MAGIC;
  
! float4trgm_limit = 0.3f;
  
  PG_FUNCTION_INFO_V1(set_limit);
  Datum set_limit(PG_FUNCTION_ARGS);
Index: contrib/tsearch2/rank.c
===
RCS file: /projects/cvsroot/pgsql/contrib/tsearch2/rank.c,v
retrieving revision 1.21
diff -c -r1.21 rank.c
*** contrib/tsearch2/rank.c 28 Dec 2006 01:09:01 -  1.21
--- contrib/tsearch2/rank.c 25 Jan 2007 12:19:30 -
***
*** 37,43 
  PG_FUNCTION_INFO_V1(get_covers);
  Datum get_covers(PG_FUNCTION_ARGS);
  
! static float weights[] = {0.1, 0.2, 0.4, 1.0};
  
  #define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )
  
--- 37,43 
  PG_FUNCTION_INFO_V1(get_covers);
  Datum get_covers(PG_FUNCTION_ARGS);
  
! static float weights[] = {0.1f, 0.2f, 0.4f, 1.0f};
  
  #define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )
  
***
*** 59,65 
  word_distance(int4 w)
  {
if (w  100)
!   return 1e-30;
  
return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
  }
--- 59,65 
  word_distance(int4 w)
  {
if (w  100)
!   return (float4)1e-30;
  
return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
  }
***
*** 331,337 
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);
  
if (res  0)
!   res = 1e-20;
  
if ((method  RANK_NORM_LOGLENGTH)  t-size  0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
--- 331,337 
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);
  
if (res  0)
!   res = (float)1e-20;

if ((method  RANK_NORM_LOGLENGTH)  t-size  0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
Index: src/include/pg_config.h.win32
===
RCS file: /projects/cvsroot/pgsql/src/include/pg_config.h.win32,v
retrieving revision 1.39
diff -c -r1.39 pg_config.h.win32
*** src/include/pg_config.h.win32   5 Jan 2007 20:54:39 -   1.39
--- src/include/pg_config.h.win32   25 Jan 2007 13:10:02 -
***
*** 366,372 
--- 366,374 
  #define HAVE_STRDUP 1

  /* Define to 1 if you have the `strerror' function. */
+ #ifndef HAVE_STRERROR
  #define HAVE_STRERROR 1
+ #endif

  /* Define to 1 if you have the `strerror_r' function. */
  /* #undef HAVE_STRERROR_R */
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.90
diff -c -r1.90 fe-secure.c
*** src/interfaces/libpq/fe-secure.c5 Jan 2007 22:20:01 -   1.90
--- src/interfaces/libpq/fe-secure.c25 Jan 2007 14:39:23 -
***
*** 575,581 
charfnbuf[MAXPGPATH];
FILE   *fp;
PGconn *conn = (PGconn *) SSL_get_app_data(ssl);
-   int (*cb) () = NULL;/* how to read user 
password */
char  

Re: [pgsql-patches] Getting rid of warnings

2007-01-26 Thread Neil Conway
On Fri, 2007-01-26 at 12:53 +0100, Magnus Hagander wrote:
 Ok, here's an updated patch per this.

Applied -- thanks for the patch.

-Neil



---(end of broadcast)---
TIP 6: explain analyze is your friend


[pgsql-patches] Getting rid of warnings

2007-01-25 Thread Magnus Hagander
Attached patch gets rid of most of the remaining warnings on a VC++
build. Summary is:
* A bunch of places that had different const specifyer in the header and
  in the body of the function. (contrib/intarray, src/timezone)
* 1.2 and such constants are double and cause warning. Define as floats
  (contrib/pg_trgm and contrib/tsearch2)
* HAVE_STRERROR is defined by python, so only conditionally redefine it
  in pg_config.h
* NULL function pointer in SSL call cast to the correct pointer type
* ssize_t is defined in pg_config_os.h, remove from libpq-int.h
* Always skip warning 4102 (label nnn: unreferenced label) caused by
  bison.
* Support for ignoring linker warnings, and ignore the warning about
  PRIVATE on DllRegisterServer. Can't fix properly because PRIVATE is
  not supported by mingw.

Index: contrib/intarray/_int_tool.c
===
RCS file: /projects/cvsroot/pgsql/contrib/intarray/_int_tool.c,v
retrieving revision 1.8
diff -c -r1.8 _int_tool.c
*** contrib/intarray/_int_tool.c4 Oct 2006 00:29:45 -   1.8
--- contrib/intarray/_int_tool.c25 Jan 2007 12:16:46 -
***
*** 188,194 

  /* len = 2 */
  bool
! isort(int4 *a, int len)
  {
int4tmp,
index;
--- 188,194 

  /* len = 2 */
  bool
! isort(int4 *a, const int len)
  {
int4tmp,
index;
Index: contrib/pg_trgm/trgm_op.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pg_trgm/trgm_op.c,v
retrieving revision 1.5
diff -c -r1.5 trgm_op.c
*** contrib/pg_trgm/trgm_op.c   30 May 2006 22:12:13 -  1.5
--- contrib/pg_trgm/trgm_op.c   25 Jan 2007 12:18:05 -
***
*** 5,11 

  PG_MODULE_MAGIC;

! float4trgm_limit = 0.3;

  PG_FUNCTION_INFO_V1(set_limit);
  Datum set_limit(PG_FUNCTION_ARGS);
--- 5,11 

  PG_MODULE_MAGIC;

! float4trgm_limit = 0.3f;

  PG_FUNCTION_INFO_V1(set_limit);
  Datum set_limit(PG_FUNCTION_ARGS);
Index: contrib/tsearch2/rank.c
===
RCS file: /projects/cvsroot/pgsql/contrib/tsearch2/rank.c,v
retrieving revision 1.21
diff -c -r1.21 rank.c
*** contrib/tsearch2/rank.c 28 Dec 2006 01:09:01 -  1.21
--- contrib/tsearch2/rank.c 25 Jan 2007 12:19:30 -
***
*** 37,43 
  PG_FUNCTION_INFO_V1(get_covers);
  Datum get_covers(PG_FUNCTION_ARGS);

! static float weights[] = {0.1, 0.2, 0.4, 1.0};

  #define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )

--- 37,43 
  PG_FUNCTION_INFO_V1(get_covers);
  Datum get_covers(PG_FUNCTION_ARGS);

! static float weights[] = {0.1f, 0.2f, 0.4f, 1.0f};

  #define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )

***
*** 59,65 
  word_distance(int4 w)
  {
if (w  100)
!   return 1e-30;

return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
  }
--- 59,65 
  word_distance(int4 w)
  {
if (w  100)
!   return (float4)1e-30;

return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
  }
***
*** 331,337 
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);

if (res  0)
!   res = 1e-20;

if ((method  RANK_NORM_LOGLENGTH)  t-size  0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
--- 331,337 
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);

if (res  0)
!   res = (float)1e-20;

if ((method  RANK_NORM_LOGLENGTH)  t-size  0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
Index: src/include/pg_config.h.win32
===
RCS file: /projects/cvsroot/pgsql/src/include/pg_config.h.win32,v
retrieving revision 1.39
diff -c -r1.39 pg_config.h.win32
*** src/include/pg_config.h.win32   5 Jan 2007 20:54:39 -   1.39
--- src/include/pg_config.h.win32   25 Jan 2007 13:10:02 -
***
*** 366,372 
--- 366,374 
  #define HAVE_STRDUP 1

  /* Define to 1 if you have the `strerror' function. */
+ #ifndef HAVE_STRERROR
  #define HAVE_STRERROR 1
+ #endif

  /* Define to 1 if you have the `strerror_r' function. */
  /* #undef HAVE_STRERROR_R */
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.90
diff -c -r1.90 fe-secure.c
*** src/interfaces/libpq/fe-secure.c5 Jan 2007 22:20:01 -   1.90
--- src/interfaces/libpq/fe-secure.c25 Jan 2007 13:21:17 -
***
*** 642,648 
return 0;
}
  #endif
!   if (PEM_read_PrivateKey(fp, pkey, cb, NULL) == NULL)
{
char   *err = 

Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Peter Eisentraut
Magnus Hagander wrote:
 * NULL function pointer in SSL call cast to the correct pointer type

Why not write NULL?

In the alternative, declare the variable to have the right type to begin 
with.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Magnus Hagander
On Thu, Jan 25, 2007 at 03:29:50PM +0100, Peter Eisentraut wrote:
 Magnus Hagander wrote:
  * NULL function pointer in SSL call cast to the correct pointer type
 
 Why not write NULL?
 
 In the alternative, declare the variable to have the right type to begin 
 with.

I went down the path of least resistance :-) Not sure if there was a
reason to code it that way from the beginning.
NULL works equally well (tested).

I assume this change is something ac ommitter can take care of at
commit-time, so I'll not resubmit for it unless asked to.

//Magnus

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes:
   bool
 ! isort(int4 *a, int len)
   {
   bool
 ! isort(int4 *a, const int len)
   {

If VC thinks that that is required to fix a warning, it's too broken to live.
AFAICS what you've got there is a compiler that is being pedantically
strict about language details that it does not actually understand well;
its apparent idea that const ** means const * const * being much in
the same line as this one.

I don't mind the non-const-related parts of this patch, but I recommend
rejecting all the const-decoration changes.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Magnus Hagander
On Thu, Jan 25, 2007 at 10:57:29AM -0500, Tom Lane wrote:
 Magnus Hagander [EMAIL PROTECTED] writes:
bool
  ! isort(int4 *a, int len)
{
bool
  ! isort(int4 *a, const int len)
{
 
 If VC thinks that that is required to fix a warning, it's too broken to live.
 AFAICS what you've got there is a compiler that is being pedantically
 strict about language details that it does not actually understand well;
 its apparent idea that const ** means const * const * being much in
 the same line as this one.

Not sure I understand.
The header had:
isort(int4 *a, const int len)
and the code had
isort(int4 *a, int len)

Where does the ** part come in there? It's not even a pointer!
I see the ** part for the free()/pfree() issues, but the one you're
quoting there is completely different. This is, AFAICS, a case of the
header not matching the body.

I'm fine with having that one rejected as well, and weill just file that
away as an expected-please-ignore warning, but I'd prefer to understand
why :)

//Magnus

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Neil Conway
On Thu, 2007-01-25 at 17:11 +0100, Magnus Hagander wrote:
 The header had:
 isort(int4 *a, const int len)
 and the code had
 isort(int4 *a, int len)

ISTM that the const keyword to an int function argument is
pointless, so the right fix is to remove the const from the
declaration in the header.

 Where does the ** part come in there? It's not even a pointer!

I believe Tom was just referencing that as an example of a
less-than-perfect compiler warning from VC++.

-Neil



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes:
 Not sure I understand.
 The header had:
 isort(int4 *a, const int len)
 and the code had
 isort(int4 *a, int len)

Oh, I see.  Yeah, that's inconsistent, though my thought would be to
remove the (rather useless) const decoration in the header.  I believe
this coding is actually legal per C99, though, precisely because the
version in the header is only decoration --- callers of the function
do not care whether it thinks the parameter value is immutable inside
itself.  The one at the function definition site is what counts ...

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Bruce Momjian

I need an updated version of this to apply.  The suggested changes are
too extensive.

---

Magnus Hagander wrote:
 Attached patch gets rid of most of the remaining warnings on a VC++
 build. Summary is:
 * A bunch of places that had different const specifyer in the header and
   in the body of the function. (contrib/intarray, src/timezone)
 * 1.2 and such constants are double and cause warning. Define as floats
   (contrib/pg_trgm and contrib/tsearch2)
 * HAVE_STRERROR is defined by python, so only conditionally redefine it
   in pg_config.h
 * NULL function pointer in SSL call cast to the correct pointer type
 * ssize_t is defined in pg_config_os.h, remove from libpq-int.h
 * Always skip warning 4102 (label nnn: unreferenced label) caused by
   bison.
 * Support for ignoring linker warnings, and ignore the warning about
   PRIVATE on DllRegisterServer. Can't fix properly because PRIVATE is
   not supported by mingw.
 

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Magnus Hagander
Bruce Momjian wrote:
 I need an updated version of this to apply.  The suggested changes are
 too extensive.


I'll try to do this tomorrow. If I get it right, the changes needed are:
NULL instead of cast of function ptr, per Peter.
Do the const-change in the other direction in contrib/intarray.

The patch never contained anything for those const ** warnings, so I'll
just continue not to include those.

If I missed anything, let me know :-)


//Magnus


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [pgsql-patches] Getting rid of warnings

2007-01-25 Thread Magnus Hagander
Tom Lane wrote:
 Magnus Hagander [EMAIL PROTECTED] writes:
 Not sure I understand.
 The header had:
 isort(int4 *a, const int len)
 and the code had
 isort(int4 *a, int len)
 
 Oh, I see.  Yeah, that's inconsistent, though my thought would be to
 remove the (rather useless) const decoration in the header.  I believe
 this coding is actually legal per C99, though, precisely because the
 version in the header is only decoration --- callers of the function
 do not care whether it thinks the parameter value is immutable inside
 itself.  The one at the function definition site is what counts ...

If it wasn't legal, it should be an error and not a warning. I would
guess it's a warning simply so you should be aware that it's ignored.
I'll update the patch for it.

//Magnus

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate