From perl-5.8.0@ton.iguana.be

Created by perl-5.8.0@ton.iguana.be

The doc for SvUTF8 says​:

  SvUTF8 Returns a boolean indicating whether the SV contains UTF-8
  encoded data.

  bool SvUTF8(SV* sv)

The code however does​:

#define SvUTF8(sv) (SvFLAGS(sv) & SVf_UTF8)

which results in an U32

That is of course no problem in constructs like​:

if (SvUTF8(sv)) { ... }

but if you do​:

  bool utf8 = SvUTF8(sv);
  ...
  if (utf8) { ... }

things fail badly because (at least on my system) the bool enum becomes a
char, and since SVf_UTF8 is 0x20000000, utf8 will always be 0 after truncate.

Either the docs or the macro should be updated I think

Several other things that are called "bool" in the api doc have the same
problem (e.g. SvIOK, SvIOKp, SvPOK, etc)

Flags:
    category=core
    severity=low

This perlbug was built using Perl v5.8.5 - Sun Nov  7 13:52:55 CET 2004
It is being executed now by  Perl v5.8.4 - Thu Jun  3 13:28:19 CEST 2004.

Site configuration information for perl v5.8.4:

Configured by ton at Thu Jun  3 13:28:19 CEST 2004.

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
  Platform:
    osname=linux, osvers=2.6.5, archname=i686-linux-64int-ld
    uname='linux quasar 2.6.5 #8 mon apr 5 05:41:20 cest 2004 i686 gnulinux '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=define
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -fomit-frame-pointer',
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.4.0 20031231 (experimental)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:



@INC for perl v5.8.4:
    /usr/lib/perl5/5.8.4/i686-linux-64int-ld
    /usr/lib/perl5/5.8.4
    /usr/lib/perl5/site_perl/5.8.4/i686-linux-64int-ld
    /usr/lib/perl5/site_perl/5.8.4
    /usr/lib/perl5/site_perl
    .


Environment for perl v5.8.4:
    HOME=/home/ton
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/ton/bin.Linux:/home/ton/bin:/home/ton/bin.SampleSetup:/opt/schily/bin:/usr/local/bin:/usr/local/sbin:/home/oracle/product/9.0.1/bin:/usr/local/ar/bin:/usr/games/bin:/usr/X11R6/bin:/usr/share/bin:/usr/bin:/usr/sbin:/bin:/sbin:.
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @nwc10

On Mon, Dec 06, 2004 at 02​:25​:52AM -0000, perl-5. 8. 0 @​ ton. iguana. be wrote​:

things fail badly because (at least on my system) the bool enum becomes a
char, and since SVf_UTF8 is 0x20000000, utf8 will always be 0 after truncate.

Either the docs or the macro should be updated I think

I think that the docs should be updated, given that people write code using
the current docs, but expect (hope?) that it works on older perls.

<hate>Yes, I've been bitten by this stupidity of "BOOL" while tweaking the
perl sources. IIRC with the UTF8 flag. I'd be quite happy to purge the perl
source of it.</hate>

Nicholas Clark

The RT System itself - Status changed from 'new' to 'open'

From @smpeters

[perl-5.8.0@​ton.iguana.be - Sun Dec 05 18​:25​:51 2004]​:

This is a bug report for perl from perl-5.8.0@​ton.iguana.be,
generated with the help of perlbug 1.35 running under perl v5.8.4.

-----------------------------------------------------------------
[Please enter your report here]

The doc for SvUTF8 says​:

   SvUTF8  Returns a boolean indicating whether the SV contains

UTF-8
encoded data.

                   bool    SvUTF8\(SV\* sv\)

The code however does​:

#define SvUTF8(sv) (SvFLAGS(sv) & SVf_UTF8)

which results in an U32

That is of course no problem in constructs like​:

if (SvUTF8(sv)) { ... }

but if you do​:

bool utf8 = SvUTF8(sv);
...
if (utf8) { ... }

things fail badly because (at least on my system) the bool enum
becomes a
char, and since SVf_UTF8 is 0x20000000, utf8 will always be 0 after
truncate.

Either the docs or the macro should be updated I think

Several other things that are called "bool" in the api doc have the
same
problem (e.g. SvIOK, SvIOKp, SvPOK, etc)

Acutally, everything looking a return value from SvFLAGS(sv) should be
looking for a U32. Since I'd like to "automate" these changes as much
as possible, how does the following look?

--- sv.h.old    Sat Sep 10 20:30:54 2005
+++ sv.h        Sat Sep 10 20:30:47 2005
@@ -703,8 +703,8 @@
                                    SvFLAGS(sv) |= (SVf_NOK|SVp_NOK))
 
 /*
-=for apidoc Am|bool|SvUTF8|SV* sv
-Returns a boolean indicating whether the SV contains UTF-8 encoded data.
+=for apidoc Am|U32l|SvUTF8|SV* sv
+Returns a U32 value indicating whether the SV contains UTF-8 encoded data.
 
 =for apidoc Am|void|SvUTF8_on|SV *sv
 Turn on the UTF-8 status of an SV (the data is not changed, just the flag).


There will probably need to be some changes in the core as well where
any of Sv*OK-like macros are on the right side of an assignment.

From @rgs

Steve Peters via RT wrote​:

Acutally, everything looking a return value from SvFLAGS(sv) should be
looking for a U32. Since I'd like to "automate" these changes as much
as possible, how does the following look?

Fine, but probably all other docs for SvFLAGS bit tests need the same
change, no ?

--- sv.h.old Sat Sep 10 20​:30​:54 2005
+++ sv.h Sat Sep 10 20​:30​:47 2005
@​@​ -703,8 +703,8 @​@​
SvFLAGS(sv) |= (SVf_NOK|SVp_NOK))

/*
-=for apidoc Am|bool|SvUTF8|SV* sv
-Returns a boolean indicating whether the SV contains UTF-8 encoded data.
+=for apidoc Am|U32l|SvUTF8|SV* sv
+Returns a U32 value indicating whether the SV contains UTF-8 encoded data.

=for apidoc Am|void|SvUTF8_on|SV *sv
Turn on the UTF-8 status of an SV (the data is not changed, just the flag).

There will probably need to be some changes in the core as well where
any of Sv*OK-like macros are on the right side of an assignment.

From @smpeters

On Mon, Sep 12, 2005 at 12​:41​:23PM +0200, Rafael Garcia-Suarez wrote​:

Steve Peters via RT wrote​:

Acutally, everything looking a return value from SvFLAGS(sv) should be
looking for a U32. Since I'd like to "automate" these changes as much
as possible, how does the following look?

Fine, but probably all other docs for SvFLAGS bit tests need the same
change, no ?

Yes, they do. They have nearly identical API doc listings, though, so
this is just the "sample" change.

From @rgs

Fixed by change #29718.

@rgs - Status changed from 'open' to 'resolved'