Commit 851f685993 ("Makefile: Add dependency between libvmcp and
libutil to fix -j builds") introduced the following regression
$ make clean
CLEAN /home2/holzheu/src/s390-tools
...
CLEAN libccw
CC libutil/util_base.o
CC libutil/util_path.o
For the "clean" target the new library dependency triggers a build
of libutil.
So remove the dependency again.
To fix the parallel build issue, no longer build the examples with
"make all" and add a new target "examples" that can now be used for building
the example programs.
Fixes: 851f685993 ("Makefile: Add dependency between libvmcp and libutil to fix -j builds")
Signed-off-by: Michael Holzheu <holzheu@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Most bootloaders use the BootLoaderSpec "title" field to name the entries
in their boot menu. The zipl bootloader used the "version" field instead,
since it was wrongly assumed that the zipl boot menu didn't support names
that contained spaces, which are usually present in a BLS "title" field.
But this is not the case, names with space characters are supported by the
IPL and is just a constraint of the section heading in the zipl.conf file.
So to be consistent with all the other bootloaders, use the "title" field
also on zipl when populating the boot menu entries from BLS files.
Closes: https://github.com/ibm-s390-tools/s390-tools/pull/47
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Stefan Haberland sth@linux.ibm.com
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use util_strlcpy() to copy log data correctly and get rid of the
following GCC8 compile warning:
zpcictl.c: In function ‘sclp_issue_action’:
zpcictl.c:312:3: warning: ‘strncpy’ specified bound 4054 equals
destination size [-Wstringop-truncation]
strncpy(report.data.log_data, sdata, sizeof(report.data.log_data));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use util_strlcpy() to copy strings correctly and get rid of the
following GCC8 compile warning:
In function ‘hmcdrv_parse_line’,
inlined from ‘hmcdrv_cache_dir’ at hmcdrvfs.c:981:11:
hmcdrvfs.c:862:4: warning: ‘strncpy’ specified bound 192 equals
destination size [-Wstringop-truncation]
strncpy(symlink, arrow + 4, HMCDRV_FUSE_MAXPATH);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
By using util_strlcpy() and correctly copying strings we can get rid of
the following GCC8 compile warnings:
In function ‘path_to_ds_name.constprop’,
inlined from ‘zdsfs_readdir’ at zdsfs.c:282:2:
zdsfs.c:78:2: warning: ‘strncpy’ specified bound 45 equals destination
size [-Wstringop-truncation]
strncpy(normds, path, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘path_to_ds_name.constprop’,
inlined from ‘zdsfs_open’ at zdsfs.c:339:2:
zdsfs.c:78:2: warning: ‘strncpy’ specified bound 45 equals destination
size [-Wstringop-truncation]
strncpy(normds, path, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘path_to_member_name.constprop’,
inlined from ‘zdsfs_open’ at zdsfs.c:372:3:
zdsfs.c:94:3: warning: ‘strncpy’ specified bound 45 equals destination
size [-Wstringop-truncation]
strncpy(normds, path, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘path_to_ds_name.constprop’,
inlined from ‘zdsfs_getxattr’ at zdsfs.c:527:2:
zdsfs.c:78:2: warning: ‘strncpy’ specified bound 45 equals destination
size [-Wstringop-truncation]
strncpy(normds, path, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘path_to_member_name.constprop’,
inlined from ‘zdsfs_getxattr’ at zdsfs.c:547:4:
zdsfs.c:94:3: warning: ‘strncpy’ specified bound 45 equals destination
size [-Wstringop-truncation]
strncpy(normds, path, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘path_to_ds_name.constprop’,
inlined from ‘zdsfs_getattr.part.1’ at zdsfs.c:134:2,
inlined from ‘zdsfs_getattr’:
zdsfs.c:78:2: warning: ‘strncpy’ specified bound 45 equals destination
size [-Wstringop-truncation]
strncpy(normds, path, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘path_to_member_name.constprop’,
inlined from ‘zdsfs_getattr.part.1’ at zdsfs.c:164:3,
inlined from ‘zdsfs_getattr’:
zdsfs.c:94:3: warning: ‘strncpy’ specified bound 45 equals destination
size [-Wstringop-truncation]
strncpy(normds, path, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use the more robust util_strlcpy() to copy strings instead of strncpy().
This fixes the following GCC8 compile warnings:
qethqoat.c: In function ‘main’:
qethqoat.c:616:2: warning: ‘strncpy’ specified bound 16 equals
destination size [-Wstringop-truncation]
strncpy(ifr.ifr_name, opts.ifname, IFNAMSIZ);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Make sure strings are copied correctly by using util_strlcpy().
Also, rename the NIC_{OWNER,NAME}_LEN definitions to *_SIZE to make it
more clear that the terminating null byte ('\0') is included in this
buffer size. Using *_LEN would mean only the number of characters in the
string fit in.
Furthermore, use these definitions rather than sizeof().
This fixes the following GCC8 compile warning:
nic.c: In function ‘nic_data_get’:
nic.c:58:2: warning: ‘strncpy’ specified bound 9 equals destination size
[-Wstringop-truncation]
strncpy(data.owner, argv[11], sizeof(data.owner));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nic.c:59:2: warning: ‘strncpy’ specified bound 9 equals destination size
[-Wstringop-truncation]
strncpy(data.name, argv[12], sizeof(data.name));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Change the buffer size to what we actually need and use util_strlcpy()
to correctly copy strings.
This gets rid of the following GCC8 compile warnings:
fcp.c: In function ‘fcp_wwpn_get’:
fcp.c:44:2: warning: ‘strncpy’ output may be truncated copying 20 bytes
from a string of length 4095 [-Wstringop-truncation]
strncpy(wwpn, buf, 20);
^~~~~~~~~~~~~~~~~~~~~~
fcp.c: In function ‘fcp_lun_get’:
fcp.c:65:2: warning: ‘strncpy’ output may be truncated copying 20 bytes
from a string of length 4095 [-Wstringop-truncation]
strncpy(lun, buf, 20);
^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use util_asprintf() to allocate memory for the string buffers
dynamically and get rid of the following GCC8 compile warnings:
system.c: In function ‘print_fw_str’:
system.c:86:46: warning: ‘%s’ directive output may be truncated writing
up to 4095 bytes into a region of size 4082 [-Wformat-truncation=]
snprintf(path, sizeof(path), "/sys/firmware/%s", file);
^~
system.c:98:19:
read_fw_str(str, path, sizeof(str));
~~~~
system.c:86:2: note: ‘snprintf’ output between 15 and 4110 bytes into a
destination of size 4096
snprintf(path, sizeof(path), "/sys/firmware/%s", file);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cmd_chreipl.c: In function ‘set_reipl_type_helper’:
cmd_chreipl.c:316:19: warning: ‘%d’ directive writing between 1 and 11
bytes into a region of size between 0 and 4095 [-Wformat-overflow=]
sprintf(cmd, "%s %d:%d", chreipl_helper, major(dev), minor(dev));
^~
cmd_chreipl.c:316:15: note: using the range [-2147483648, 2147483647]
for directive argument
sprintf(cmd, "%s %d:%d", chreipl_helper, major(dev), minor(dev));
^~~~~~~~~~
cmd_chreipl.c:316:15: note: using the range [-2147483648, 2147483647]
for directive argument
cmd_chreipl.c:316:2: note: ‘sprintf’ output between 5 and 4120 bytes
into a destination of size 4096
sprintf(cmd, "%s %d:%d", chreipl_helper, major(dev), minor(dev));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use util_strlcpy() to copy strings correctly and get rid of the
following GCC8 compile warnings:
main.c: In function ‘main’:
main.c:34:2: warning: ‘strncpy’ specified bound 256 equals destination
size [-Wstringop-truncation]
strncpy(g.prog_name, argv[0], sizeof(g.prog_name));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘set_bootprog’,
inlined from ‘parse_chreipl_options’ at cmd_chreipl.c:510:4:
cmd_chreipl.c:185:2: warning: ‘strncpy’ specified bound 11 equals
destination size [-Wstringop-truncation]
strncpy(l.bootprog, bootprog, sizeof(l.bootprog));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cmd_chreipl.c: In function ‘set_reipl_type’:
cmd_chreipl.c:297:2: warning: ‘strncpy’ specified bound 15 equals
destination size [-Wstringop-tr uncation]
strncpy(l.dev, dev_name, sizeof(l.dev));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Copy strings correctly by using util_strlcpy() over strncpy() and get
rid of the following GCC8 compile warning:
In function ‘dinfo_extract_dev’,
inlined from ‘dinfo_get_dev_from_blockdev’ at dasdinfo.c:365:6:
dasdinfo.c:337:2: warning: ‘strncpy’ specified bound 80 equals
destination size [-Wstringop-trunc ation]
strncpy(tmp, str, RD_BUFFER_SIZE);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
IFNAMSIZ is the maximum buffer size for an interface name, including its
terminating zero byte. [1] strncpy() should therefore only copy a size
of 'IFNAMSIZ - 1' and the destination string should then be
null-terminated properly.
Use util_strlcpy() to correctly copy the string and get rid of the
followin GCC8 compile warning:
In function ‘ethtool_checksumming’,
inlined from ‘process_sysfs_attribute’ at lsqeth.c:333:5,
inlined from ‘print_device’ at lsqeth.c:468:3:
lsqeth.c:171:2: warning: ‘strncpy’ specified bound 16 equals destination
size [-Wstringop-truncat ion]
strncpy(ifr.ifr_name, if_name, IFNAMSIZ);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[1]: https://www.gnu.org/software/libc/manual/html_node/Interface-Naming.html
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Get rid of fixed buffers and avoid the following GCC8 compile warnings:
lszcrypt.c: In function ‘main’:
lszcrypt.c:642:28: warning: ‘%04x’ directive writing between 4 and 8
bytes into a region of size between 7 and 13 [-Wformat-overflow=]
sprintf(sub_dev, "%02x.%04x", id, dom);
^~~~
lszcrypt.c:642:22: note: directive argument in the range [0, 2147483647]
sprintf(sub_dev, "%02x.%04x", id, dom);
^~~~~~~~~~~
lszcrypt.c:642:5: note: ‘sprintf’ output between 8 and 18 bytes into a
destination of size 16
sprintf(sub_dev, "%02x.%04x", id, dom);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
DEV_NAME_SIZE is defined as IFNAMSIZ. IFNAMSIZ is the maximum buffer size
for an interface name, including its terminating null byte. [1] The
buffers dev_name and ifr_name are both defined with a size of
DEV_NAME_SIZE and IFNAMSIZ respectively.
Given these facts, only a size of 'IFNAMSIZ - 1' should be copied and
the destination string should then be null-terminated properly.
Use util_strlcpy() to correctly copy the strings and rid of the followin
GCC8 compile warnings:
xcec-bridge.c: In function ‘open_incoming_socket’:
xcec-bridge.c:94:2: warning: ‘strncpy’ specified bound 16 equals
destination size [-Wstringop-tru ncation]
..strncpy(if_req.ifr_name,dev_name,DEV_NAME_LEN);
..^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xcec-bridge.c: In function ‘read_sys’:
xcec-bridge.c:284:4: warning: ‘strncpy’ output may be truncated copying
16 bytes from a string of length 255 [-Wstringop-truncation]
....strncpy(is->dev_name, if_name, DEV_NAME_LEN);
....^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[1]: https://www.gnu.org/software/libc/manual/html_node/Interface-Naming.html
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The term 'len' only represents the number of characters in a string,
as opposed to 'size' which means the number of bytes including the
terminating null byte ('\0').
DEV_NAME_LEN is defined as IFNAMSIZ, so we are clearly interested in the
size. Rename to DEV_NAME_SIZE to make this more clear.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The strlcpy() implementation in libu2s is beneficial for other tools as
well. Move the implementation to libutils and replace misc_strlcpy() in
libu2s accordingly.
Change the link order in zipl to make it build again.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Safely replace strncpy() with memcpy() as we don't want the terminating
null byte anyway. Get rid of the following warning:
dasdview.c: In function ‘dasdview_print_volser’:
dasdview.c:621:3: warning: ‘strncpy’ output truncated before terminating
nul copying 6 bytes from a string of the same length
[-Wstringop-truncation]
strncpy(volser, " ", 6);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
While assembling the volume label, strncpy() is used. As we don't care
about NUL termination of the strings here, safely replace strncpy() with
memcpy() and get rid of the following compile warnings:
fdasd.c: In function ‘fdasd_write_vtoc_labels’:
fdasd.c:1324:4: warning: ‘strncpy’ output truncated before terminating
nul copying 44 bytes from a string of the same length
[-Wstringop-truncation]
strncpy(ch, "LINUX.V "
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
" ", 44);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fdasd.c:1332:4: warning: ‘strncpy’ output truncated before terminating
nul copying 5 bytes from a string of the same length
[-Wstringop-truncation]
strncpy(c1, ".PART", 5);
^~~~~~~~~~~~~~~~~~~~~~~
In function ‘fdasd_write_vtoc_labels’,
inlined from ‘fdasd_write_labels’ at fdasd.c:1399:3:
fdasd.c:1329:4: warning: ‘strncpy’ output may be truncated copying 6
bytes from a string of length 6 [-Wstringop-truncation]
strncpy(c1, volser, VOLSER_LENGTH);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fdasd.c:1336:4: warning: ‘strncpy’ output may be truncated copying 5
bytes from a string of length 5 [-Wstringop-truncation]
strncpy(c1, dsno, 5);
^~~~~~~~~~~~~~~~~~~~
fdasd.c:1340:4: warning: ‘strncpy’ output truncated before terminating
nul copying as many bytes from a string as its length
[-Wstringop-truncation]
strncpy(c1, dsname, strlen(dsname)); /* We don't want \0 */
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fdasd.c:1313:4: warning: ‘strncpy’ output may be truncated copying 31
bytes from a string of length 44 [-Wstringop-truncation]
strncpy(c1, s2, 31);
^~~~~~~~~~~~~~~~~~~
In function ‘fdasd_change_part_type’,
inlined from ‘main’ at fdasd.c:3000:4:
fdasd.c:1639:3: warning: ‘strncpy’ output may be truncated copying 6
bytes from a string of length 19 [-Wstringop-truncation]
strncpy(ch, str, 6);
^~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
We can safely replace strncpy() with memcpy() here and get rid of the
following compile warnings:
dfi_s390mv.c: In function ‘set_magic_numbers’:
dfi_s390mv.c:570:3: warning: ‘strncpy’ output truncated before
terminating nul copying 7 bytes fr om a string of the same length
[-Wstringop-truncation]
strncpy(l.dumper_magic, DF_S390_DUMPER_MAGIC_MV_EXT, 7);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dfi_s390mv.c:573:3: warning: ‘strncpy’ output truncated before
terminating nul copying 7 bytes fr om a string of the same length
[-Wstringop-truncation]
strncpy(l.dumper_magic, DF_S390_DUMPER_MAGIC_MV, 7);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Using inappropriate sizes for snprintf() leads to the following compile
warnings:
dfi_s390mv.c: In function ‘dev_from_busid’:
dfi_s390mv.c:116:34: warning: ‘/online’ directive output may be
truncated writing 7 bytes into a region of size between 1 and 4096
[-Wformat-truncation=]
snprintf(tmp_file, PATH_MAX, "%s/online", dev_file);
^~~~~~~
dfi_s390mv.c:116:2: note: ‘snprintf’ output between 8 and 4103 bytes
into a destination of size 4096
snprintf(tmp_file, PATH_MAX, "%s/online", dev_file);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dfi_s390mv.c:143:35: warning: ‘%s’ directive output may be truncated
writing up to 255 bytes into a region of size between 0 and 4095
[-Wformat-truncation=]
snprintf(tmp_file, PATH_MAX, "%s/%s/dev", dev_file, direntp->d_name);
^~
dfi_s390mv.c:143:2: note: ‘snprintf’ output between 6 and 4356 bytes
into a destination of size 4096
snprintf(tmp_file, PATH_MAX, "%s/%s/dev", dev_file, direntp->d_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A simple fix would be to use different suitable fixed sizes for tmp_file
and dev_file. However, the code can be improved here a little.
Use the libutil function util_path_sysfs() to build the sysfs path
string. This is more robust, as the function will figure out the correct
mount point of the sysfs. util_path_sysfs() will also terminate
execution, if no sysfs mount point could be found. That means, we can
get rid of check_sysfs().
Furthermore, the two variables (tmp_file, dev_file) can be combined to
one. Also, check the return value of open() and act accordingly.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use misc_asprintf() for concatenating strings and get rid of the
following GCC8 compile warnings:
disk.c: In function ‘disk_get_info’:
disk.c:247:43: warning: ‘%d’ directive output may be truncated writing
between 1 and 11 bytes int o a region of size between 0 and 79
[-Wformat-truncation=]
snprintf(ppn_cmd, sizeof(ppn_cmd), "%s %d:%d",
^~
disk.c:247:39: note: using the range [-2147483648, 2147483647] for
directive argument
snprintf(ppn_cmd, sizeof(ppn_cmd), "%s %d:%d",
^~~~~~~~~~
disk.c:247:39: note: using the range [-2147483648, 2147483647] for
directive argument
disk.c:247:4: note: ‘snprintf’ output between 5 and 104 bytes into a
destination of size 80
snprintf(ppn_cmd, sizeof(ppn_cmd), "%s %d:%d",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
script_file, major(stats.st_rdev),
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
minor(stats.st_rdev));
~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Using the DATA_SIZE() macro gets rid of the following GCC8 compile
warning:
boot.c: In function ‘boot_init_fba_stage0’:
boot.c:120:2: warning: ‘memcpy’ forming offset [2, 152] is out of the
bounds [0, 1] of object ‘_binary_fba0_bin_start’ with type ‘char’
[-Warray-bounds]
memcpy(stage0, DATA_ADDR(fba0), sizeof(*stage0));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from boot.c:18:
../boot/data.h:24:13: note: ‘_binary_fba0_bin_start’ declared here
extern char _binary_fba0_bin_start;
^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
With GCC8 the following warning is displayed:
In file included from cio.h:15,
from stage2.h:15,
from menu.h:15,
from stage2.c:14:
s390.h:193:1: warning: alignment 1 of ‘struct _lowcore’ is less than 8
[-Wpacked-not-aligned]
} __packed;
^
Fix by aligning struct _lowcore to double page size.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The message buffer of DumpException doesn't account for additional
strings such as strerror(), device nodes, or filenames. Make it a bit
larger to be safe.
This fixes the following GCC8 compile warnings:
In file included from vm_dump.h:62,
from vm_dump.cpp:17:
dump.h: In static member function ‘static Dump::DumpType
VMDump::getDumpType(const char*)’:
dump.h:46:16: warning: ‘ (’ directive writing 2 bytes into a region of size
between 1 and 200 [-W format-overflow=]
sprintf(msg, "%s (%s)", m, strerror(errno));
^~~~~~~~~
dump.h:46:10: note: ‘sprintf’ output 4 or more bytes (assuming 203) into a
destination of size 200
sprintf(msg, "%s (%s)", m, strerror(errno));
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dump.h:46:16: warning: ‘ (’ directive writing 2 bytes into a region of size
between 1 and 200 [-W format-overflow=]
sprintf(msg, "%s (%s)", m, strerror(errno));
^~~~~~~~~
dump.h:46:10: note: ‘sprintf’ output 4 or more bytes (assuming 203) into a
destination of size 200
sprintf(msg, "%s (%s)", m, strerror(errno));
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dump.h:46:16: warning: ‘ (’ directive writing 2 bytes into a region of size
between 1 and 200 [-W format-overflow=]
sprintf(msg, "%s (%s)", m, strerror(errno));
^~~~~~~~~
dump.h:46:10: note: ‘sprintf’ output 4 or more bytes (assuming 203) into a
destination of size 200
sprintf(msg, "%s (%s)", m, strerror(errno));
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To assemble things like the volume id or fields of the format1 label
struct, strncpy() is used. Data copied here is later written to disk and
we don't want any terminating null byte ('\0') there. Therefore, we can
simply use memcpy() instead and get rid of the following GCC8 compile
warnings:
vtoc.c: In function ‘vtoc_init_format_1_8_label’:
vtoc.c:747:2: warning: ‘strncpy’ output truncated before terminating nul
copying 6 bytes from a s tring of the same length [-Wstringop-truncation]
strncpy((char *) f1->DS1DSSN, " ", 6);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vtoc.c:746:2: warning: ‘strncpy’ output may be truncated copying 44 bytes from
a string of length 79 [-Wstringop-truncation]
strncpy(f1->DS1DSNAM, str, 44);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vtoc.c:761:2: warning: ‘strncpy’ output may be truncated copying 13 bytes from
a string of length 79 [-Wstringop-truncation]
strncpy((char *)f1->DS1SYSCD, str, 13);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vtoc.c: In function ‘vtoc_volume_label_set_volser’:
vtoc.c:401:2: warning: ‘strncpy’ output may be truncated copying 6 bytes from a
string of length 6 [-Wstringop-truncation]
strncpy(vlabel->volid, s, VOLSER_LENGTH);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
fread()/fwrite() return the unsigned count of elements read/written or a
short count or zero in case of an error. Check if the number of elements
read/written matches the expectation. In case of fread(), if it does not
match, check if an error occurred and otherwise assume the file to be too
small. In case of fwrite(), if it does not match, assume an error.
Resolves Cppcheck style warnings:
[zkey/pkey.c:161]: (style) Checking if unsigned variable 'count' is less than zero.
[zkey/pkey.c:209]: (style) Checking if unsigned variable 'count' is less than zero.
[zkey/pkey.c:299]: (style) Checking if unsigned variable 'count' is less than zero.
Cc: Ingo Franzki <ifranzki@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When realloc() fails to allocate memory it returns NULL and the original
block is left untouched. In that case return the potentially larger
original block.
Found using Cppcheck:
[zdev/src/misc.c:1106]: (error) Memory leak: name
Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The modified flag was actually never copied during merge of setting lists.
Copy the modified flag if requested.
Found using Cppcheck:
[zdev/src/setting.c:553]: (warning) Redundant assignment of 'n->modified' to itself.
Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The computation of blk in functions fdasd_check_volume() and
fdasd_write_vtoc_labels() contained the possibility for an undetected
unsigned integer overflow. Unconditionally subtracting one from the
return value of function cchhb2blk() may cause an unsigned integer
overflow, as cchhb2blk() may return zero if cc, hh, and b are all zero.
Resolves Cppcheck style warning:
[fdasd/fdasd.c:1260]: (style) Checking if unsigned variable 'blk' is less than zero.
Cc: Stefan Haberland <sth@linux.ibm.com>
Cc: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Only check if size is zero and not if equal or less than zero. This is
safe, as size is only decremented by rlen, which is either less than or
equal to size. So size may never overflow.
Resolves Cppcheck style warning:
[cmsfs-fuse/cmsfs-fuse.c:3746]: (style) Checking if unsigned variable 'size' is less than zero.
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For linking the "libvmcp" example program the "libutil" is required.
Therefore when the "libvmcp" directory is entered in a parallel build
and the "libutil.a" file has not yet been created, a second "libutil"
build is triggered which can then lead to build errors like the following:
ar: libutil.a: File format not recognized
ar: libutil.a: No such file or directory
make[2]: Leaving directory '/builddir/build/BUILD/s390-tools-2.6.0/libutil'
make[2]: *** [../common.mak:246: libutil.a] Error 1
make[1]: *** [../common.mak:246: libutil.a] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [../common.mak:315: ..//libutil/libutil.a] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/s390-tools-2.6.0/libvmcp'
make: *** [Makefile:57: libvmcp] Error 2
make: *** Waiting for unfinished jobs....
ving directory '/builddir/build/BUILD/s390-tools-2.6.0/libutil'
make: *** [Makefile:57: libutil] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.wCulxB (%build)
So fix this and add a dependency between libvmcp and libutil.
Signed-off-by: Michael Holzheu <holzheu@linux.ibm.com>
Reviewed-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When using 'zkey cryptsetup' with the '--run' option,
it might not find the executable to execute when those
are in /sbin.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Change all error messages from printf() to warnx().
While at it, remove the punctuation mark for some of the error messages.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The .o.d make targets in common.mak do not expect that
header files are generated by a make target. When a new header
file is generated, the .o.d targets will be rebuilt on the
next make invocation, because that new header file is then
detected, and is then treated as a new dependency of all .o.d
targets.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The linux.vnet.ibm.com addresses will be become disfunct by eoy.
Signed-off-by: Stefan Raspl <raspl@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add the missing identifiers to report the card name and link speed.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>