Your question is hard to answer because you don't mention the layer you are looking at.
There at least four layers to consider:
Usually the hardware consists of some administrative blocks, the "payload" blocks and some spare blocks. A hard drive contains some dozen and an SSD drive up to 15% of the official size of spare/reserve blocks. Bad blocks are remapped to the spare/reserve blocks by the drive's firmware. The operating system only knows the size of the payload blocks. Some low-level disk tools (e.g. Spinrite) may read out the number of available spare blocks.
Depending on the size of the hard disk - propagated by the firmware/hd-controller to your EFI/operating system - your partitioning tool (e.g. Disk Utility) may create partitions by determining start values and end values for each partition in the partition table. The free space on your hard disk is determined by the final block of the last partition and the beginning of the second GPT table (provided that you partitioned your drive continuously and gaps don't exist). You may read out the free space on your hard disk with
Usually partitions have to be formatted with a file system to be usable. Almost all important filesystems contain a volume bitmap. The volume bitmap is a representation of all (file system) blocks or clusters of a volume. Free blocks and occupied blocks are marked differently. So one method to determine the free space on a volume is counting all blocks tagged free in the volume bitmap.
LVM layer (Logical Volume Manager) or CoreStorage
The LVM layer is an abstraction layer in between hard disks, partitions and volumes. Though determined by the basic partitions ("Physical Volumes") a Logical Volume may span over several Physical Volumes (Fusion Drive). I don't know it for sure, but a Logical Volume Group probably contains a counterpart of a partition table holding all informations about all contained objects (like Physical Volume(s), Logical Volume Family(ies), Logical Volume(s)). The available free space may be read out by entering
diskutil cs list
block/cluster layer (this is not relevant for OS X file systems)
Some file systems support block suballocation. In short words: A lot of files don't occupy a full block/cluster of the volume layer because they are smaller than the block/cluster size. In the free space of the cluster you may store a second/third/forth small file. I don't know how to determine this free space (probably some i-node/B-Tree magic).
Depending on the layer you may now choose the appropriate method or tool to determine the "free space of your hard disk".