On Tue, Apr 24, 2012 at 06:40:27PM -0400, Mansour Moufid wrote: > On 12-04-24 8:01 AM, Kenneth R Westerback wrote: > >On Tue, Apr 24, 2012 at 01:05:52AM -0400, Mansour Moufid wrote: > >>In getenv.c, the __findenv function is changed to use size_t for its > >>length parameter, and ptrdiff_t for its offset parameter. > >>The getenv function is modified accordingly. > >> > >>In setenv.c, the setenv function is also modified to match the changes > >>to __findenv, as well as to use size_t for all variables representing > >>object sizes. > >>--- > >Even better than in-lining the diff would be to provide a cvs diff > >rather than a git diff. The official tree is distributed and > >maintained in cvs, and thus we can't know what or where your git > >tree comes from. A cvs diff also usually includes the information > >necessary to find out where the diff applies. And some developers just > >don't react well to git. :-) > Oops, sorry. I appended a cvs diff at the end of this message. > >Just reading the diff, since I'm not sure how or where to apply it, > >I can't see much need for or concern about environment information > >larger than MAXINT in size. Nor am I a fan of the (to me) silly > >proliferation of types like ptrdiff_t. > Good point. Here, because of the for loops, the difference is > always positive, so I changed it to size_t. > >Is there some standards/known constraint/current behaviour on other > >unix's that this would address? > Nothing in particular. But using signed types to represent lengths > is generally considered harmful, especially in tandem with malloc. > Also, the behaviour of a cast to int (signed) from size_t > (unsigned; as with l_value below) is implementation-defined when > the value is not representable in the signed type. Other than > that, this patch is just for the sake of correctness.
You'd have to define 'correctness' more precisely. i.e. how does the current code fail? i.e. how is it currently 'incorrect'. If you say these changes will make environment variables 2 billion characters long 'safe', I'd have to stick to my original difficulty in raising concern. :-) > > Thanks for the feedback. I'm mostly curious if the OpenBSD > developer community is interested in typing issues. I'm working on > a static analysis tool (+ source transformation; this is the type > of output it produces), and testing the waters. The OpenBSD is extremely interested in typing issues! And is a heavy consumer of various static analyzers to shake out bugs. But the community is also occasionally hostile to apparently pointless changes unless real advantages are made clear. :-) .... Ken
