Hi,
I needed to "format" a binary string with a series of "shorts" or WORDs.
The values I provided to "binary format s" were out of range, but "binary format" accepted them.
I am surprised, that providing integers, that are out of range are accepted to "format" specified integer of a lower range by an implicit cast:
% set v [clock seconds]
1348734108
% format {%#x %#x} {*}[scan [set bin [binary format s $v]] {%c%c}]
0x9c 0xc
% set s [expr {$v & 0xFFFF}]
3228
% expr {$s == [binary scan $bin s s2; set s2]}
1
This behavior is not documented, is it wanted or just a bug?
And why the following:
% binary format s [clock milliseconds]
integer value too large to represent
Is the acceptable integer range still limited to non-wide integers?
Why not here casting implicitly?
Best regards,
Martin

On 26/09/2012 21:43, Rene Zaumseil wrote:
> Am Mittwoch, 26. September 2012, 22:23:35 schrieb Michael Schlenker:
> > gcc 3.0.4 docs claim this should be supported:
> >
> > http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_5.html#SEC94
> >
> > If thats not the case on IRIX, you should add a guard to that clause
> > so the simple TCL_FORMAT_PRINTF(a,b) version is used, the __format__
> > stuff just does some extra security checks to detect bad printf usage
> > patterns.
>
> Yeah, I could do it. But should it not come out of the box?
But none of us know why it is broken on your system, and it sounds like
it is probably a problem in the GCC documentation, or maybe in your
installation. In any case, given that it is a simple thing to fix from
your perspective (just change the arm of the '#if' taken), explain why
we should something weird just to support your particular build on a
platform that's no longer supported by its vendor with a compiler that's
no longer supported by its vendor. There's a limit to what we can do.
If we were to move to support this, we'd want to do it by adding more
stuff to Tcl's configure script. But that's an area which is only really
for the foolhardy (it's just cruft upon cruft, worse even than the
ifdeffery in tclUnix*).
Donal (I'm so glad I no longer use IRIX64...)

Larry McVoy wrote:
> Rene Zaumseil wrote:
> > Simulators have a long lifetime. This was first build around 1995.
> > And then it could be a bug? At least it was working before.
>
> [...]
>
> You're using an ancient compiler on a dead platform (*) and asking people
> who have no way of reproducing your problem, to fix it. That's just asking
> too much in my opinion.
>
> Your options are:
>
> - submit a patch that fixes it
> - get someone else to compile you a release
> - upgrade your compiler
> - move your simulator (seriously? You are running a simulator on an
> incredibly slow CPU? I could simulate a MIPS faster on modern x86
> hardware)
I can sympathise with Renee; I've been in that situation.
(Cost of an X86 PC that can run circles around an 1995-era MIPS box
is less than US$300. Cost of getting that X86 PC deployed into an
existing commercial or military simulator environment can be
tens of thousands of dollars and man-months of effort.)
In this case: if it's just the one blob of #ifdeffery that's
giving you trouble, your best bet is just to patch it locally.
I'd be reluctant to accept that patch upstream though.
Changing this:
#if defined(__GNUC__) && (__GNUC__ > 2)
which says to maintainers: "This feature is available in GCC 3.X and up" --
into this:
#if defined(__GNUC__) && (__GNUC__ > 2) && !defined(__IRIX__)
(meaning "... except it didn't work on this one guy's IRIX box
this one time back in September 2012...") is a maintenance drag.
#ifdefs in the code base have a habit of lasting even longer
than simulators... There's still a ton of #ifdeffed goo in
tcl/unix/tclUnix*.c dating as far back as '91 that as far as
anyone can tell has been utterly obsolete since well before
the turn of the century, but nobody can remove it because of
fear.
--Joe English
jenglish@...