Custom Query (541 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (28 - 30 of 541)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Ticket Resolution Summary Owner Reporter
#153 invalid Fix addr() macro in libsrc/lib330/pascal.h somebody baker
Description

gcc complains (warnings) about incompatible pointer types numerous times when compiling source files in src/libsrc/lib330, such as:

/usr/bin/gcc -g -m32 -Dlinux -D__i386 -D_LINUX -D_INTEL -D_USE_SCHED -D_USE_PTHREADS -D_USE_TERMIOS
 -I/home/baker/earthworm/earthworm-7.5/merged/include   -c -o libarchive.o libarchive.c
libarchive.c: In function ‘flush_archive’:
libarchive.c:118: warning: passing argument 1 of ‘strcpy’ from incompatible pointer type
libarchive.c:118: warning: passing argument 2 of ‘strcpy’ from incompatible pointer type
libarchive.c:119: warning: passing argument 1 of ‘strcpy’ from incompatible pointer type
libarchive.c:119: warning: passing argument 2 of ‘strcpy’ from incompatible pointer type
libarchive.c: In function ‘preload_archive’:
libarchive.c:451: warning: passing argument 1 of ‘strcpy’ from incompatible pointer type
libarchive.c:451: warning: passing argument 2 of ‘strcpy’ from incompatible pointer type
libarchive.c:452: warning: passing argument 1 of ‘strcpy’ from incompatible pointer type
libarchive.c:452: warning: passing argument 2 of ‘strcpy’ from incompatible pointer type

This occurs wherever the addr() macro is used, which is defined in src/libsrc/lib330/pascal.h as:

#define addr &

, such as in lines 118 and 119 in src/libsrc/lib330/libarchive.c:

  strcpy(addr(q330->miniseed_call.location), addr(q->slocation)) ;
  strcpy(addr(q330->miniseed_call.channel), addr(q->sseedname)) ;

The incompatibility occurs when the required type (the dummy arguments to strcpy(), in this case) is a pointer to a scalar and the addr() macro is applied to an array. In that case, addr() produces a pointer to an array, which is not a compatible type.

From ANSI/ISO C 1989/1990, section 6.2.2.1, Lvalues and function designators:

Except when it is the operand of the sizeof operator or the unary & operator, or is a character
string ... wchar_t, an lvalue that has type "array of type" is converted to an expression that has
type "pointer to type" that points to the initial element of the array object and is not an lvalue.

The fix is to define addr() to cast the result after application of the & operator as a void*, which is compatible with every pointer-to-scalar type:

#define addr(x) ((void *) &x)
#154 fixed Bug fix for archman somebody baker
Description

gcc warns that src/archiving/archman/archman.c is incorrectly assigning an integer to a pointer:

/Users/baker/bin/gcc -D_REENTRANT -m32 -D_MACOSX -D_INTEL -D_GFORTRAN -D_USE_PTHREADS
 -D_USE_SCHED -I/Users/baker/Desktop/Software/Earthworm/earthworm-7.5/merged/include -Ilib -Ilib
   -c -o archman.o archman.c
archman.c: In function ‘get_time_data’:
archman.c:989: warning: assignment makes pointer from integer without a cast

The error is in the assignment of cal_time at line 989 in the following code fragment (lines 985-998):

    /* write to the log file */
    if (config->log_data_msgs)
    {
      epoch_time = (time_t) trace_header->starttime;
      cal_time = timegm_ew (&epoch_time);
      if (!cal_time)
      {
        year = month = day = hour = min = sec = milli = 0;
        duration = 0.0;
      }
      else
      {
        year  = cal_time->tm_year + 1900;
        month = cal_time->tm_mon + 1;

The reason is that timegm_ew() returns a time_t, not a struct tm*:

time_t     timegm_ew   ( struct tm * );

gmtime_ew() is the Earthworm time function that returns a struct tm*:

struct tm *gmtime_ew( const time_t *epochsec, struct tm *res )
{
    gmtime_r( epochsec, res );
    return( res );
}

The fix is to #include "time_ew.h"

#include "trace_buf.h"
#include "time_ew.h"

and call gmtime_ew() instead of timegm_ew():

      gmtime_ew (&epoch_time, cal_time);

A patch is attached to the ticket.

#155 fixed Extra characters after #endif in wave_serverV somebody baker
Description

gcc version 4.1.2 (CentOS 5.6 x86_64) complains (warnings) about extra tokens following an #endif directive:

/usr/bin/gcc -D_REENTRANT -m32 -Dlinux -D__i386 -D_LINUX -D_INTEL -D_USE_SCHED
 -D_USE_PTHREADS -D_USE_TERMIOS -I/home/baker/earthworm/earthworm-7.5/merged/include
 -g -c -o wave_serverV.o wave_serverV.c
wave_serverV.c:1016:8: warning: extra tokens at end of #endif directive

Lines 1015-1016 in src/archiving/wave_serverV/wave_serverV.c are missing C comment delimiters around the closing tags:

#endif _WINNT
#endif _SOLARIS

The fix is:

#endif /* _WINNT */
#endif /* _SOLARIS */

A patch is attached to the ticket.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Note: See TracQuery for help on using queries.