openbsd/src/lib/libc/stdlib/setenv.c, branch OPENBSD_6_8_BASE A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE 2016-09-21T04:38:56+00:00 Delete casts to off_t and size_t that are implied by assignments 2016-09-21T04:38:56+00:00 guenther 2016-09-21T04:38:56+00:00 urn:sha1:4f42c802703f53d8169bb55766b44a362a136d7c or prototypes. Ditto for some of the char* and void* casts too. verified no change to instructions on ILP32 (i386) and LP64 (amd64) ok natano@ abluhm@ deraadt@ millert@ Allow setenv(3) and putenv(3) to operate on a NULL environ pointer. 2016-04-25T21:36:04+00:00 millert 2016-04-25T21:36:04+00:00 urn:sha1:baeeab2cbccd4d08a37d92c62ca5f237ea8e7dc6 The getenv(3) and unsetenv(3) functions already support this. This will make it easier to emulate the glibc clearenv() function in ports. Based on a diff from and OK jca@ environ and __progname are not declared in a public header; declare them 2016-03-13T18:34:21+00:00 guenther 2016-03-13T18:34:21+00:00 urn:sha1:8e31f7b09b8e135e165df08a971ac10c71f4d29a in libc's hidden/stdlib.h instead of in each .c file that needs one ok deraadt@ gsoares@ mpi@ Wrap <stdlib.h> so that calls go direct and the symbols not in the 2015-09-13T08:31:48+00:00 guenther 2015-09-13T08:31:48+00:00 urn:sha1:e85bde5645a66155108c2a88d25fa62993a3f2bb C standard are all weak. Apply __{BEGIN,END}_HIDDEN_DECLS to gdtoa{,imp}.h, hiding the arch-specific __strtorx, __ULtox_D2A, __strtorQ, __ULtoQ_D2A symbols. using reallocarray() gives us multiplicative integer overflow checking 2014-10-08T05:33:31+00:00 deraadt 2014-10-08T05:33:31+00:00 urn:sha1:d1aebe19824d65f2950bada1883ba29804d12b34 in case something wants to create massive amounts of environment, like a bit more than 1/4 of a 32-bit address space. unrealistic -- but why audit one code path, and not treat others the same? then you have to re-engage everytime you see the code. read the news, that isn't what developers do. At least if the code paths look the same, there is hope, because they are easier to verify for correctness. developers need to give other developers a chance to want to care. Make setenv(3) consistent with unsetenv(3), giving EINVAL if passed 2012-09-23T16:08:04+00:00 jeremy 2012-09-23T16:08:04+00:00 urn:sha1:be49cd9e087c09cea5ec0276d663efd8564fa0d5 an empty name, NULL pointer, or a name containing an '=' character. OK millert@, guenther@ Check for duplicate variables in the environment when setting a value 2010-08-23T22:31:50+00:00 millert 2010-08-23T22:31:50+00:00 urn:sha1:1e367116e85e839002afc69614bb7d21565126b6 via setenv() or putenv(). OK miod@ Make unsetenv(NULL) and unsetenv("") give EINVAL, per POSIX. ok deraadt@ 2010-06-29T04:09:34+00:00 naddy 2010-06-29T04:09:34+00:00 urn:sha1:ea27549635fddb5047499ce46c454d3acfe0df83 Don't assume that we can overwrite strings in the environment. 2009-06-04T20:39:13+00:00 millert 2009-06-04T20:39:13+00:00 urn:sha1:b77bc4fc41b396fdfad2c3601e64aa26f6c0ed7f Someone may have passed a read-only string to putenv() (I'm looking at you cron!). Make putenv(), setenv() and unsetenv() standards compliant. The 2009-06-03T15:52:16+00:00 millert 2009-06-03T15:52:16+00:00 urn:sha1:2fbee47dd731557e4c361a39c72b272faeeefe8d standard explicitly disallows passing setenv a name with a '=' in it but historic BSD behavior is to allow this but to ignore the '=' and anything after it.