fsck.ubifs: fix platform dependant ino_t and loff_t formatting

On architectures such as armv7-a, ino_t and loff_t are unsigned long long rather than
unsigned long. In such cases, the printf format specifier "%lu" is not
appropriate and causes an incorrect address offset.

  mtd-utils/ubifs-utils/fsck.ubifs/problem.c:224
  		log_out(c, "problem: %s, ino %lu, unreachable dentry %s, type %s%s",
  			problem->desc, ifp->file->inum,
  			c->encrypted && !ifp->file->ino.is_xattr ? "<encrypted>" : dent_node->name,
  			ubifs_get_type_name(dent_node->type),
  			key_type(c, &dent_node->key) == UBIFS_XENT_KEY ? "(xattr)" : "");

  fsck.ubifs[484] (/dev/ubi0_0,danger mode): problem: Dentry is unreachable, ino 917, unreachable dentry (null), type checksum_typefile

Furthermore, running fsck.ubifs with the --debug=4 option will almost
certainly cause a SEGV at the following point.

  mtd-utils/ubifs-utils/fsck.ubifs/check_files.c:103
  	dbg_fsck("construct file(%lu) for %s node, TNC location %d:%d, in %s",
  		 inum, ubifs_get_key_name(key_type(c, key)), sn->lnum, sn->offs,
  		 c->dev_name);

To ensure functionality regardless of environment, cast ino_t to unsigned
long, since it will never be more than 4 bytes.

For loff_t, use %lld and cast accordingly.

Signed-off-by: Yuta Hayama <hayama@lineo.co.jp>
Signed-off-by: Tomas Alvarez Vanoli <tomas.alvarez-vanoli@hitachienergy.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>

0 files changed, 0 insertions, 0 deletions