Re: [ANNOUNCE] VDR developer version 1.3.47

Hi,

attached is an update for the romanian strings.

Lucian
Common subdirectories: vdr-1.3.47_orig/PLUGINS and vdr-1.3.47/PLUGINS
  

Hi,

beneath notice and sorry if already known, but:

g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD 
-DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE 
-DVIDEODIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\"  recording.c
recording.c: In constructor 'cIndexFile::cIndexFile(const char*, bool)':
recording.c:1200: warning: format '%d' expects type 'int', but argument 
3 has type 'long unsigned int'


gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)


BR,

Christian
  

Christian Wieninger wrote:
> Hi,
> 
> beneath notice and sorry if already known, but:
> 
> g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD 
> -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE 
> -DVIDEODIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\"  recording.c
> recording.c: In constructor 'cIndexFile::cIndexFile(const char*, bool)':
> recording.c:1200: warning: format '%d' expects type 'int', but argument 
> 3 has type 'long unsigned int'
> 
> 
> gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)

Strange... I have the same compiler version here

kls@hawk:/home/kls/vdr/VDR > g++ -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 
--enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)


but I don't get that warning.
I could change it to "%u" (which makes sense, since the value is
actually unsigned), but when I change it to "%lu" I get

g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\"  recording.c
recording.c: In constructor 'cIndexFile::cIndexFile(const char*, bool)':
recording.c:1200: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'


Just in case, my kernel version is

Linux hawk 2.6.13-15.8-default #1 Fri Feb 10 16:26:01 CET 2006 i686 i686 i386 GNU/Linux


I'm not sure what to make of this...

Klaus
  

Am Samstag, 22. April 2006 12:17 schrieb Klaus Schmidinger:
> Strange... I have the same compiler version here

I just notice, that I also don't get the warning on a machine at home, where I 
run the same system and compiler. The warning occures on a machine at office, 
where I just did a quick compile test. The only difference between the two 
systems is, that the office machine runs the 64-bit edition of Suse 10, while 
at home it's the 32-bit edition. Perhaps that's the reason.

> I'm not sure what to make of this...

perhaps nothing ;-)

Christian
  

Hi,

Christian Wieninger wrote:

>> Strange... I have the same compiler version here

Me, too ;-)

> I just notice, that I also don't get the warning on a machine at home, where I 
> run the same system and compiler. The warning occures on a machine at office, 
> where I just did a quick compile test. The only difference between the two 
> systems is, that the office machine runs the 64-bit edition of Suse 10, while 
> at home it's the 32-bit edition. Perhaps that's the reason.

It is.

>> I'm not sure what to make of this...
> 
> perhaps nothing ;-)

I've got a report of a similar warning in vdr-xine. I suggest this solution:

esyslog("ERROR: can't allocate %ld bytes for index '%s'", (long)(size * 
sizeof(tIndex)), fileName);

Bye.
  

Reinhard Nissl wrote:
> Hi,
> 
> Christian Wieninger wrote:
> 
>>> Strange... I have the same compiler version here
> 
> 
> Me, too ;-)
> 
>> I just notice, that I also don't get the warning on a machine at home, 
>> where I run the same system and compiler. The warning occures on a 
>> machine at office, where I just did a quick compile test. The only 
>> difference between the two systems is, that the office machine runs 
>> the 64-bit edition of Suse 10, while at home it's the 32-bit edition. 
>> Perhaps that's the reason.
> 
> 
> It is.
> 
>>> I'm not sure what to make of this...
>>
>>
>> perhaps nothing ;-)
> 
> 
> I've got a report of a similar warning in vdr-xine. I suggest this 
> solution:
> 
> esyslog("ERROR: can't allocate %ld bytes for index '%s'", (long)(size * 
> sizeof(tIndex)), fileName);

To be honest, I don't like this.
Shouldn't this work on both 32- and 64bit systems without the need of
typecasting?

Klaus
  

Klaus Schmidinger wrote:
> Reinhard Nissl wrote:
> 
>>
>> I've got a report of a similar warning in vdr-xine. I suggest this
>> solution:
>>
>> esyslog("ERROR: can't allocate %ld bytes for index '%s'", (long)(size
>> * sizeof(tIndex)), fileName);
> 
> 
> To be honest, I don't like this.
> Shouldn't this work on both 32- and 64bit systems without the need of
> typecasting?

The return type of sizeof() is size_t. The size of size_t is
implementation-defined. With GCC that's unsigned int on ix86 and
unsigned long on x86_64.
  

Anssi Hannula wrote:
> Klaus Schmidinger wrote:
> 
>>Reinhard Nissl wrote:
>>
>>
>>>I've got a report of a similar warning in vdr-xine. I suggest this
>>>solution:
>>>
>>>esyslog("ERROR: can't allocate %ld bytes for index '%s'", (long)(size
>>>* sizeof(tIndex)), fileName);
>>
>>
>>To be honest, I don't like this.
>>Shouldn't this work on both 32- and 64bit systems without the need of
>>typecasting?
> 
> 
> The return type of sizeof() is size_t. The size of size_t is
> implementation-defined. With GCC that's unsigned int on ix86 and
> unsigned long on x86_64.

Does this mean that one would have to use different conversion
specifiers on 32- and 64bit systems? Sounds like a compiler bug
to me, because the source code should compile corretcly on both
systems...

Klaus
  

On Sunday 23 April 2006 10:43, Klaus Schmidinger wrote:
> Anssi Hannula wrote:
> > Klaus Schmidinger wrote:
> >>Reinhard Nissl wrote:
> >>>I've got a report of a similar warning in vdr-xine. I suggest this
> >>>solution:
> >>>
> >>>esyslog("ERROR: can't allocate %ld bytes for index '%s'", (long)(size
> >>>* sizeof(tIndex)), fileName);
> >>
> >>To be honest, I don't like this.
> >>Shouldn't this work on both 32- and 64bit systems without the need of
> >>typecasting?
> >
> > The return type of sizeof() is size_t. The size of size_t is
> > implementation-defined. With GCC that's unsigned int on ix86 and
> > unsigned long on x86_64.
>
> Does this mean that one would have to use different conversion
> specifiers on 32- and 64bit systems? Sounds like a compiler bug
> to me, because the source code should compile corretcly on both
> systems...

"man fprintf" says there is a special "z" length modifier for size_t
arguments, so "...%zd..." should do the trick

/Werner
  

Am Sonntag, 23. April 2006 11:21 schrieb Werner Schweer:
> On Sunday 23 April 2006 10:43, Klaus Schmidinger wrote:
> > Anssi Hannula wrote:
> > > Klaus Schmidinger wrote:
> > >>Reinhard Nissl wrote:
> > >>>I've got a report of a similar warning in vdr-xine. I suggest this
> > >>>solution:
> > >>>
> > >>>esyslog("ERROR: can't allocate %ld bytes for index '%s'", (long)(size
> > >>>* sizeof(tIndex)), fileName);
> > >>
> > >>To be honest, I don't like this.
> > >>Shouldn't this work on both 32- and 64bit systems without the need of
> > >>typecasting?
> > >
> > > The return type of sizeof() is size_t. The size of size_t is
> > > implementation-defined. With GCC that's unsigned int on ix86 and
> > > unsigned long on x86_64.
> >
> > Does this mean that one would have to use different conversion
> > specifiers on 32- and 64bit systems? Sounds like a compiler bug
> > to me, because the source code should compile corretcly on both
> > systems...
>
> "man fprintf" says there is a special "z" length modifier for size_t
> arguments, so "...%zd..." should do the trick

"...%zd..." can be used, no compile error on a 64bit only system and 32bit 
system.

Gerald

>
> /Werner
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr