2

In the refs related to <sys/types.h> the type blkcnt_t is defined as:

blkcnt_t Used for file block counts.

also it states:

blkcnt_t and off_t shall be signed integer types.

(see http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_67)

I was unable to find the rationale for the number of blocks ever being negative, hence I wonder why the type is defined signed?

While I cannot imagine well the use of files having a negative number of blocks, I would think that blkcnt_t might be assigned a negative value to signify some sort of error/exceptional condition?

Fun fact is that the blkcnt_t type was introduced as unsigned (see here) and then later changed to be signed (see here). As description/rationale why this change happend this commit message is given:

"blkcnt_t and off_t shall be signed integer types." This causes pacman to fail when the size requirement of the net update operation is negative, instead it calculated a huge positive number.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
  • 1
    You're comparing two different codebases here. The first link is the Linux kernel, the second one cygwin. blkcnt_t is still unsigned in the Linux kernel: http://lxr.free-electrons.com/source/include/linux/types.h#L131. – lgeorget Mar 22 '17 at 10:29

2 Answers2

2

I imagine it’s signed to support signed arithmetic, or rather storing signed block count deltas (which is what tripped up pacman and prompted the Cygwin patch you mention).

In the Linux kernel it is still still unsigned.

Stephen Kitt
  • 434,908
0

This is probably just for backwards compatibility. In earlier versions there was no blkcnt_t type but the field had simply been long. So when they moved to a more flexible specification they probably wanted to keep the signedness of the field.