'%l[dox]' isn't very long.

[p5pRT]

Migrated from rt.perl.org#8934 (status was 'resolved')

Searchable as RT8934$

[p5pRT]

From @abigail

Created by @abigail

I would expect the (s)printf formatters %lo\, %ld\, and %lx to be able to deal integers correctly for at least the values that are dealt with correctly by %o\, %d and %x.

Unfortunally\, that isn't true.

  my $shift = 32;   printf "%lo\, %o\n" => 1 \<\< $shift\, 1 \<\< $shift;   printf "%ld\, %d\n" => 1 \<\< $shift\, 1 \<\< $shift;   printf "%lx\, %x\n" => 1 \<\< $shift\, 1 \<\< $shift;   __END__

This will print​:   0\, 40000000000   0\, 4294967296   0\, 100000000

I expected​:   40000000000\, 40000000000   4294967296\, 4294967296   100000000\, 100000000

Abigail

Perl Info

``` Flags: category=core severity=low Site configuration information for perl v5.7.3: Configured by abigail at Fri Apr 12 02:04:48 CEST 2002. Summary of my perl5 (revision 5.0 version 7 subversion 3 patch 15863) configuration: Platform: osname=linux, osvers=2.4.5, archname=i686-linux-64int-ld uname='linux hermione 2.4.5 #6 fri jun 22 01:38:20 pdt 2001 i686 unknown ' config_args='-des -Uversiononly -Dmydomain=.foad.org -Dcf_email=abigail@foad.org -Dperladmin=abigail@foad.org -Doptimize=-g -Dusemorebits -Dusedevel -Dusenm=false -Dprefix=/opt/perl/@15863' 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=n, bincompat5005=define Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/opt/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/opt/local/include' ccversion='', gccversion='2.95.3 20010315 (release)', 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 -L/opt/local/lib' libpth=/usr/local/lib /opt/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.3.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib -L/opt/local/lib' Locally applied patches: DEVEL15844 @INC for perl v5.7.3: /home/abigail/Perl /home/abigail/Sybase /opt/perl/@15863/lib/5.7.3/i686-linux-64int-ld /opt/perl/@15863/lib/5.7.3 /opt/perl/@15863/lib/site_perl/5.7.3/i686-linux-64int-ld /opt/perl/@15863/lib/site_perl/5.7.3 /opt/perl/@15863/lib/site_perl . Environment for perl v5.7.3: HOME=/home/abigail LANG (unset) LANGUAGE (unset) LC_ALL=POSIX LD_LIBRARY_PATH=/home/abigail/Lib:/usr/local/lib:/usr/lib:/lib:/usr/X11R6/lib:/opt/gnome/lib LOGDIR (unset) PATH=/home/abigail/Bin:/opt/perl/bin:/usr/local/bin:/usr/local/X11/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/games:/opt/povray/bin:/opt/gnome/bin:/opt/opera/bin:/usr/share/texmf/bin:/opt/Acrobat4/bin:/opt/java/blackdown/j2sdk1.3.1/bin:/usr/local/games/bin:/opt/gnuplot/bin:/opt/mysql/bin PERL5LIB=/home/abigail/Perl:/home/abigail/Sybase PERLDIR=/opt/perl PERL_BADLANG (unset) SHELL=/usr/bin/bash ```

[p5pRT]

From @vanstyn

abigail@​foad.org wrote​: :I would expect the (s)printf formatters %lo\, %ld\, and %lx :to be able to deal integers correctly for at least the :values that are dealt with correctly by %o\, %d and %x.

Why? I think you're getting what you asked for - without 'l'\, you get an IV size\, which is 'long long' according to your configuration. With 'l'\, we cast to 'long' (4 bytes) which is correctly 0.

Are you saying we should define the 'l' modifier to be ignored if sizeof(IV) > sizeof(long)?

Hugo

[p5pRT]

From @abigail

On Fri\, Apr 12\, 2002 at 06​:54​:27PM +0100\, Hugo van der Sanden wrote​:

abigail@​foad.org wrote​: :I would expect the (s)printf formatters %lo\, %ld\, and %lx :to be able to deal integers correctly for at least the :values that are dealt with correctly by %o\, %d and %x.

Why? I think you're getting what you asked for - without 'l'\, you get an IV size\, which is 'long long' according to your configuration. With 'l'\, we cast to 'long' (4 bytes) which is correctly 0.

Are you saying we should define the 'l' modifier to be ignored if sizeof(IV) > sizeof(long)?

Well\, according the documentation of sprintf\, the 'l' modifier interprets the integer as a 'long'. With no flags\, it should be treated as an 'int'.

And\, AFAIK\, sizeof(int) \<= sizeof(long). Now\, I'm not at all against %o/%d/%x to "do the right thing"\, but shouldn't %lo/%ld/%lx do the same thing?

I would not expect something to be truncated to a 'long' where it isn't truncated to an 'int'.

Perhaps all that's needed is a doc fix?

Abigail

[p5pRT]

From @jhi

On Fri\, Apr 12\, 2002 at 08​:14​:30PM +0200\, abigail@​foad.org wrote​:

On Fri\, Apr 12\, 2002 at 06​:54​:27PM +0100\, Hugo van der Sanden wrote​:

abigail@​foad.org wrote​: :I would expect the (s)printf formatters %lo\, %ld\, and %lx :to be able to deal integers correctly for at least the :values that are dealt with correctly by %o\, %d and %x.

Why? I think you're getting what you asked for - without 'l'\, you get an IV size\, which is 'long long' according to your configuration. With 'l'\, we cast to 'long' (4 bytes) which is correctly 0.

Are you saying we should define the 'l' modifier to be ignored if sizeof(IV) > sizeof(long)?

Well\, according the documentation of sprintf\, the 'l' modifier interprets the integer as a 'long'. With no flags\, it should be treated as an 'int'.

Yes\, but here you are making the assumption that without the flags a [dox] is an "int". Even with 32-bit builds\, it isn't\, it's (usually) a "long". It's just a curse of (C's) history that "int" and "long" have been mistaken to be idnetical.

And\, AFAIK\, sizeof(int) \<= sizeof(long). Now\, I'm not at all against %o/%d/%x to "do the right thing"\, but shouldn't %lo/%ld/%lx do the same thing?

It probably should\, for consistency (with Perl\, if not C) -- but if so\, then the whole 'l' prefix becomes a complete no-op.

I would not expect something to be truncated to a 'long' where it isn't truncated to an 'int'.

Perhaps all that's needed is a doc fix?

Abigail

-- $jhi++; # http​://www.iki.fi/jhi/   # There is this special biologist word we use for 'stable'.   # It is 'dead'. -- Jack Cohen

[p5pRT]

From @abigail

On Fri\, Apr 12\, 2002 at 09​:24​:02PM +0300\, Jarkko Hietaniemi wrote​:

On Fri\, Apr 12\, 2002 at 08​:14​:30PM +0200\, abigail@​foad.org wrote​:

On Fri\, Apr 12\, 2002 at 06​:54​:27PM +0100\, Hugo van der Sanden wrote​:

abigail@​foad.org wrote​: :I would expect the (s)printf formatters %lo\, %ld\, and %lx :to be able to deal integers correctly for at least the :values that are dealt with correctly by %o\, %d and %x.

Why? I think you're getting what you asked for - without 'l'\, you get an IV size\, which is 'long long' according to your configuration. With 'l'\, we cast to 'long' (4 bytes) which is correctly 0.

Are you saying we should define the 'l' modifier to be ignored if sizeof(IV) > sizeof(long)?

Well\, according the documentation of sprintf\, the 'l' modifier interprets the integer as a 'long'. With no flags\, it should be treated as an 'int'.

Yes\, but here you are making the assumption that without the flags a [dox] is an "int". Even with 32-bit builds\, it isn't\, it's (usually) a "long". It's just a curse of (C's) history that "int" and "long" have been mistaken to be idnetical.

I'm not making any assumptions\, other than what the documentation promises me. (Yes\, after 2 decade in computing\, I'm still horribly naive!) It's the docs that say it shall be treated as a C 'int'.

Perhaps my bug report should have been that %[dox] isn't correctly truncating the values. ;-)

And\, AFAIK\, sizeof(int) \<= sizeof(long). Now\, I'm not at all against %o/%d/%x to "do the right thing"\, but shouldn't %lo/%ld/%lx do the same thing?

It probably should\, for consistency (with Perl\, if not C) -- but if so\, then the whole 'l' prefix becomes a complete no-op.

I don't think that's too bad; the current behaviour doesn't seen useful to me. I know the heritage\, and that's its coming from C\, where you do need the 'l' flag to prevent truncation to 'int'. Besides\, aren't the flags 'll'\, 'L' and 'q' already no-ops?

Abigail

[p5pRT]

From @jhi

Yes\, but here you are making the assumption that without the flags a [dox] is an "int". Even with 32-bit builds\, it isn't\, it's (usually) a "long". It's just a curse of (C's) history that "int" and "long" have been mistaken to be idnetical.

I'm not making any assumptions\, other than what the documentation promises me. (Yes\, after 2 decade in computing\, I'm still horribly naive!)

:-)

It's the docs that say it shall be treated as a C 'int'. Perhaps my bug report should have been that %[dox] isn't correctly truncating the values. ;-)

I'm afraid you'll soon find the 'h'...

And\, AFAIK\, sizeof(int) \<= sizeof(long). Now\, I'm not at all against %o/%d/%x to "do the right thing"\, but shouldn't %lo/%ld/%lx do the same thing?

It probably should\, for consistency (with Perl\, if not C) -- but if so\, then the whole 'l' prefix becomes a complete no-op.

I don't think that's too bad; the current behaviour doesn't seen useful to me. I know the heritage\, and that's its coming from C\, where you do need the 'l' flag to prevent truncation to 'int'. Besides\, aren't the flags 'll'\, 'L' and 'q' already no-ops?

Hmmm. They are no-ops in a different sense​: the cause the format to be skipped completely (just as if you'd used\, say\, "%zz") if used with a non-quad-built Perl.

Abigail

-- $jhi++; # http​://www.iki.fi/jhi/   # There is this special biologist word we use for 'stable'.   # It is 'dead'. -- Jack Cohen

[p5pRT]

From @abigail

On Fri\, Apr 12\, 2002 at 09​:53​:53PM +0300\, Jarkko Hietaniemi wrote​:

It's the docs that say it shall be treated as a C 'int'. Perhaps my bug report should have been that %[dox] isn't correctly truncating the values. ;-)

I'm afraid you'll soon find the 'h'...

AH\, but that does what I expect it to do from reading the documentation. ;-)

Not that I can remember ever having used 'h' (except when writing test cases for an implementation of sprintf I once wrote in LPC).

I don't think that's too bad; the current behaviour doesn't seen useful to me. I know the heritage\, and that's its coming from C\, where you do need the 'l' flag to prevent truncation to 'int'. Besides\, aren't the flags 'll'\, 'L' and 'q' already no-ops?

Hmmm. They are no-ops in a different sense​: the cause the format to be skipped completely (just as if you'd used\, say\, "%zz") if used with a non-quad-built Perl.

Oh\, we could always make '%lo' skip the format if Perl ever gets compiled on a platform without longs. ;-)

Anyway\, it's weekend. Without email access. ;-)

Abigail

[p5pRT]

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