illumos gate

what is your platform and gcc version?

i'm using DilOS with gcc-4.8:

$ gcc-4.8 -m64 -o p p.c

igor@infra-99-018:/myshare/ssd02/builds/dilos-illumos.lx/9$ ./p
1777777777777777777777

igor@infra-99-018:/myshare/ssd02/builds/dilos-illumos.lx/9$ ./p | od -Ax -tx1
000000 31 37 37 37 37 37 37 37 37 37 37 37 37 37 37 37
000010 37 37 37 37 37 37
000016

all fine

I checked on OpenIndiana hipster-20151003 (and newer) mainly, but I don't know gcc version which built libc.

This problem depends on compiler (the way of making stack layout of _ndoprnt).
Actually, OpenIndiana-151a8 does not reproduce it (maybe using gcc-4.4.x).

Kiichi Ozaki wrote:

I checked on OpenIndiana hipster-20151003 (and newer) mainly, but I don't know gcc version which built libc.

This problem depends on compiler (the way of making stack layout of _ndoprnt).
Actually, OpenIndiana-151a8 does not reproduce it (maybe using gcc-4.4.x).

gcc-4.4 test based on my DilOS:

igor@infra-99-018:/myshare/ssd02/builds/dilos-illumos.lx/9$ /usr/gcc/4.4/bin/gcc -m64 -o p p.c 
igor@infra-99-018:/myshare/ssd02/builds/dilos-illumos.lx/9$ ./p
1777777777777777777777igor@infra-99-018:/myshare/ssd02/builds/dilos-illumos.lx/9$ 
igor@infra-99-018:/myshare/ssd02/builds/dilos-illumos.lx/9$ ./p | od -Ax -tx1
000000 31 37 37 37 37 37 37 37 37 37 37 37 37 37 37 37
000010 37 37 37 37 37 37
000016

as you can see - all the same with gcc-4.8.
i have my own builds of gcc44 and gcc48 with patches for illumos builds, but patches based on Rich Lowe patches for illumos.

Oh, The problem is in libc, so it doesn't matter what gcc version building test program (p.c) is.

At any rate, I think that the current source code (about the value of MAXLLDIGS) is problematic.

Kiichi Ozaki wrote:

At any rate, I think that the current source code (about the value of MAXLLDIGS) is problematic.

but i have no problems on my dilos env :)
but i'm using gcc-4.8 for dilos-illumos builds

Yeah, OI Hipster seems to be broken. As others pointed out, this appears to be an issue with libc and not the compiler used to compile the test program.

jeffpc@meili:/tmp$ clang -m64 -o test-clang print.c
jeffpc@meili:/tmp$ gcc -m64 -o test-gcc print.c  
jeffpc@meili:/tmp$ ./test-gcc | xxd                
0000000: 0037 3737 3737 3737 3737 3737 3737 3737  .777777777777777
0000010: 3737 3737 3737                           777777
jeffpc@meili:/tmp$ ./test-clang | xxd
0000000: 0037 3737 3737 3737 3737 3737 3737 3737  .777777777777777
0000010: 3737 3737 3737                           777777

OK :)

my point was to:
[environment]
OpenIndiana (hipster) and other illumos distributions.

if you say about 'and other illumos distributions' - you need provide result with distribution name :)
for now - it confirmed on OI, but i can't confirm with DilOS
will wait others distributions

I just tried on OmniOS 018 - also broken.

I'm guessing that it is likely related to gcc 4.4.4 which most illumos distros use.

What I mean is, as wrote at ticket description, that there is an out-of-bounds bug in illumos libc code whether incorrect output reproduces or not maybe because of compiler.

Finally,

buf[-1] is '1'
buf[ 0] is '7'
...
buf[20] is '7'

and bp points &buf[-1].

Thank you for reporting this Kiichi. Your analysis here looks correct and that we have undersized the buffer and are accessing this out of bounds it appears. It's quite obvious especially if you modify your second example to start several bytes in.

#include <stdio.h>
#include <string.h>

int
main(void)
{
        int i;
        char buf[32];

        memset(buf, 'r', sizeof (buf));
        sprintf(buf + 4, "%lo", ~0L);

        for (i = 0; i < 32; i++) {
                printf("%d: %x\n", i, buf[i]);
        }

        return (0);
}

Kiichi, do you want to prepare a change for this and some tests or should I take care of that?

Thank you, but I'm not able to edit description. May I ask?

Kiichi, sorry I missed your comment here. You should be able to now.