On 11 November 2013 12:30, Jonathan Wakely <jwakely....@gmail.com> wrote:
> On 8 November 2013 10:29, Bernhard Reutner-Fischer wrote:
>>> On 04/11/2013 02:04 PM, Bernhard Reutner-Fischer wrote:
>>>>
>>>> I would have expected that somebody would tell me that omitting ::tmpnam
>>>> violates 27.9.2 <cstdio> from the spec but noone yelled at me yet?
>
> std::tmpnam, like std::gets, should be killed with fire. If a target C
> library doesn't provide it then I have no problem is libstdc++ doesn't
> provide it either.
>
>> Attaching an updated patch that i was using since March (without
>> regressions) which takes Rainer's comments about _GLIBCXX_USE_TMPNAM
>> into account.
>> Ok for trunk?
>
> Thanks for following this up.
>
> I'm curious why you use tmpnam("NULL") rather than tmpnam(NULL) or
> tmpnam("something")? Using the string literal "NULL" is a bit
> confusing (although not a problem.)
Yea, perhaps that's confusing, let's use "XYZ" instead.
>
> How does __UCLIBC_SUSV4_LEGACY__ get defined? We'd have a problem if
> users defined that at configure time but not later when using the
> library.
That would be defined by uClibc's configury, but the latest
"commit-6f2faa2" i attached does not mention this anymore, but does
the check in a libc-agnostic manner?
