signed vs unsigned

Robert Helling helling at lmu.de
Wed Mar 23 13:07:33 PDT 2016


Hi,

> On 23.03.2016, at 16:15, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> We have certain values that are unsigned because of the C standard.
> sizeof() for example. We have other values that are semantically always
> non-negative (temperature in K, pressure in a vessel).
> 
> The initial reason for doing all this "cleanup" work was to silence the
> more than a thousand warnings one gets when building for iOS (where these
> warnings are forced on). And in the process I tried to be smart and use
> signed vs unsigned in ways that made sense given what the variables
> actually were supposed to contain.

to continue in this vain, I did a git grep unsigned and found a few more cases that I would like to discuss before trying to turn this into a patch. Once more, I would propose to make everything signed unless you have a very good reason not to. I would not touch anything that does bit operations like dive computer communication, cryptographic algorithms etc for obvious reasons. But there are a few places where one could argue that „there might be a reason where one wants negative values“. These are

- duration_t contains unsigned seconds. And it is not only used for actual durations. We might run into semantic problems when we allow things to happen before the dive, but there might be reasons for that (the time a picture is taken). I see no reason to restrict these to positive and this would imply a few follow up changes.

- volumes (and similar pressures) sound like things that cannot be negative. But they can, for example in planning a dive that uses too much gas.

- depth can be negative when the planner does a step of ascent that happens to be greater than the previous depth. This is a signal of reaching the surface.

In particular dive.c holds a number of „unsigned“’s that I would get rid of for aesthetic reasons.

What do you think?

Best
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160323/6158289f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160323/6158289f/attachment.sig>


More information about the subsurface mailing list