> Tim Peters <tim.one@comcast.net> writes: > > > [martin@v.loewis.de] > > > That, OTOH, is not what Guido wants it to be. Guido wants Py_Malloc to > > > return 0 *only* in case of failure; allocating 0 bytes should > > > "normally" succeed. I still cannot see what problems you have with > > > this requirement. > > > > I'm not following this at all. Calling malloc(1) does exactly what Guido > > wants. "malloc(1)" isn't a broken Unix manpage reference, if that's how > > you're reading it; it means call malloc with an argument of 1. > > I think I'm now getting to the root of your confusion. Calling > malloc(1) is *not* what Guido wants. Instead, he wants that > py_malloc(0) returns a non-null pointer "normally". > > Now, there are some C libraries which normally return a NULL pointer > for malloc(0); as you point out, C gives them the freedom to do so. To > work-around this under-specification, one can call malloc(1) - > standards mandate that this does attempt to allocate something. It may > be possible to find different work-arounds, but this is the most > straight-forward one. I'm still confused. What is the difference between calling malloc(1) and returning a non-null pointer "normally" ? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4