Why does the return value -1 become 4294967295 when return type is int64_t？

Question

In this code, I have a function whose return value is -1, but when assigned to int64_t type, the value obtained is 4294967295 instead of -1, but when assigned to int32_t type, it is -1. The return value of that zip_name_locate is of type int (4 bytes on my system). why is that?

#include <inttypes.h>
#include <stdio.h>
#include <zip.h>

int main() {
    const char * path = "/home/www/api/default/current/public/static/doc/test.xlsx";

    int error = ZIP_ER_NOENT;
    zip_t* zip = zip_open(path, ZIP_RDONLY, &error);

    int32_t n = zip_name_locate(zip, "xl/worksheets/_rels/sheet2.xml.rels", ZIP_FL_NODIR);
    printf("%d\n", n);

    int64_t j = zip_name_locate(zip, "xl/worksheets/_rels/sheet2.xml.rels", ZIP_FL_NODIR);
    printf("%" PRId64 "\n", j);

    return 0;
}

output：

-1
4294967295

Answer 1

This is my system information:

➜  ~ uname -r
3.10.0-1062.12.1.el7.x86_64
➜  ~ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
➜  ~ gcc --version                           
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks for answering, here are some answers to your questions：

• About libzip, Because this is related to a bug I encountered in the process, so I need to use zip
• My system is 64bit CentOS 7.7
• zip_name_locate does return zip_int64_t type
• I printed n and j in gdb, n is -1, j is 4196160, it seems that gdb cannot print integers of type int64_t, but this output indicates that j should not be -1
• Because we used an old version of libzip in a certain environment and caused a bug, so we wanted to find the most fundamental reason, we used the built-in version 0.11
• PRId64 is ld on my system
• int64_t j = -1; and int64_t j = (int64_t)((zip_int64_t)-1); successful conversion
• sizeof(long) is 8

I made a mistake. On my system, I have an old version of libzip and a new version of libzip, but when I tried to introduce the old version of libzip with the -L flag, the new version was actually introduced. The method I compiled is gcc -L /usr/lib64 -lzip test1.c -o test and /usr/lib64 is where the old version of libzip dynamic shared library is located.

In my system, there are some libzip library files under /usr/lib64 and /usr/local/lib64, the old version under /usr/lib64, and the new version under /usr/local/lib64:

ls -lh /usr/local/lib64/libzip.so*
lrwxrwxrwx 1 root root   11 Jun  1 22:21 /usr/local/lib64/libzip.so -> libzip.so.5
lrwxrwxrwx 1 root root   13 Jun  1 22:21 /usr/local/lib64/libzip.so.5 -> libzip.so.5.3
-rwxr-xr-x 1 root root 162K Jun  1 23:18 /usr/local/lib64/libzip.so.5.3

ls -lh /usr/lib64/libzip.so* 
-rwxr-xr-x 1 root root 57K Jun  2 00:02 /usr/lib64/libzip.so
lrwxrwxrwx 1 root root  11 Jun  2 00:07 /usr/lib64/libzip.so.2 -> libzip.so.5
-rwxr-xr-x 1 root root 57K Jun  2 00:02 /usr/lib64/libzip.so.2.1.0
-rwxr-xr-x 1 root root 57K Jun  2 00:02 /usr/lib64/libzip.so.5

I learned that the objdump command can check which shared libraries are dependent, so I checked it out and the following is the output:

objdump -p test | grep so                 
  NEEDED               libzip.so.2
  NEEDED               libc.so.6
  required from libc.so.6:

Then I checked through ldconfig and found that libzip.so.2 points to the new version:

ldconfig -v | grep libzip
    libzip.so.5 -> libzip.so.5.3
    libzip.so.2 -> libzip.so.5

So in my question, it was based on a wrong judgment from the beginning, leading to incomprehensible imagination. If you are using a new version of libzip, the return value of zip_name_locate of libzip in the new version is zip_int64_t. This type is int64_t type on my system. When the 4294967295 return value of this type is assigned to int32_t, it causes overflow, so would be -1, and j would be 4294967295.