Describe the bug In this function

robj *createStringObjectFromLongLongWithOptions(long long value, int valueobj) {
    robj *o;

    if (server.maxmemory == 0 ||
        !(server.maxmemory_policy & MAXMEMORY_FLAG_NO_SHARED_INTEGERS))
    {
        /* If the maxmemory policy permits, we can still return shared integers
         * even if valueobj is true. */
        valueobj = 0;
    }

    if (value >= 0 && value < OBJ_SHARED_INTEGERS && valueobj == 0) {
        incrRefCount(shared.integers[value]);
        o = shared.integers[value];
    } else {
        if (value >= LONG_MIN && value <= LONG_MAX) {
            o = createObject(OBJ_STRING, NULL);
            o->encoding = OBJ_ENCODING_INT;
            o->ptr = (void*)((long)value);
        } else {
            o = createObject(OBJ_STRING,sdsfromlonglong(value));
        }
    }
    return o;
}

I see when value >= LONG_MIN && value <= LONG_MAX, the func directly assign the value(which is a long long value) to the ptr(which is a pointer) without alloc the memory for the ptr. The value is passed in the func as a parameter, which means its memory is on the stack, not on the heap. I think this may be a bug.

To reproduce

NA

Expected behavior

NA

Additional information

Any additional information that is relevant to the problem.

Comment From: sundb

@zhang-wen-guang This is not a bug, the scope of void* is the same as long, at the point the address of o->ptr is the value of value, then you can not treat o->ptr as a normal pointer. This is just to save some memory space, otherwise, we would need to like createObject(OBJ_INT, value)

Comment From: zhang-wen-guang

@zhang-wen-guang This is not a bug, the scope of void* is the same as long, at the point the address of o->ptr is the value of value, then you can not treat o->ptr as a normal pointer. This is just to save some memory space, otherwise, we would need to like createObject(OBJ_INT, value)

Thank you very much, I understand it now. That's a very cool design!