[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

**To**:**tech-userlevel%NetBSD.org@localhost****Subject**:**Re: detecting integer over/underflow****From**:**Mouse <mouse%Rodents-Montreal.ORG@localhost>**- Date: Sun, 4 Mar 2012 17:55:14 -0500 (EST)

> __overflow(type, value) > That returns false if value fits in type, and true if not. For your purposes, this sounds reasonable. That is, it sounds as though it would satisfy the desire you cite. But I think there is a subtle psychological hazard here. Even under the __type_fit name, this gives the impression of being a "does this computation overflow" (or "does this computation fit into this type") test, which it isn't. For example, there's a strong temptation to write something like __type_fit(intmax_t, x * y) to find out if the multiplication result fits in an intmax_t. But of course such a test will never fail for intmax_t, and even for smaller types can fail in unobvious ways, as in int x; int y; ... __type_fit(int,x*y) which also will never fail, even if int is smaller tha intmax_t and the multiplication does indeed overflow, because the multiplication will be an int*int->int operation, truncated before it's tested. This is not a problem if it's used only in the cases you've designed it for. But, after seeing the disaster that NULL has become, I have no real faith that people will use such a thing only within its original design parameters. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse%rodents-montreal.org@localhost / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

**References**:**detecting integer over/underflow***From:*Christos Zoulas

- Prev by Date:
**Re: detecting integer over/underflow** - Next by Date:
**Re: Adding missing __printflike attributions** - Previous by Thread:
**Re: detecting integer over/underflow** - Next by Thread:
**fsck(8) and superblock backups** - Indexes: