by Chris » Tue Apr 07, 2009 2:28 pm
randi wrote:Chris wrote:These changes aren't BSD-specific, but are more for cleaning away older-styled code (malloc.h is deprecated, fmod.h shouldn't be included in non-fmod code, __va_copy is an internal function/replaced by va_copy in C99, kill() needs signal.h).
The manpages I read indicated you needed to include malloc.h to get malloc_usable_size. Is this no longer the case? Malloc.h is also listed as a
required header for VC++. Is malloc.h really deprecated, or is FreeBSD overly critical?
Probably a bit of both. I don't know why a system would flat-out throw an error over using an old header instead of just a warning. My Linux manpages don't seem to have malloc_usable_size, although the page for malloc says stdlib.h.
However, it seems you're right. Including stdlib.h instead of malloc.h doesn't give malloc_usable_size. Interesting.
http://www.slac.stanford.edu/comp/unix/ ... alloc.html says it's under stdlib.h, but it also says "`malloc_usable_size' is not portable." so I would expect some issues there regardless. I guess it would be best to leave m_alloc.cpp alone, then, until a CMake check is made to find which header it's in (can't say I'm in a hurry to do that).
I don't remember why I used __va_copy instead of va_copy, but I know there was a reason.
Perhaps because va_copy is C99, but MinGW was stuck at GCC 3.4 which didn't have it? That would be my guess, anyway. My man pages say:
Code: Select all
va_copy()
An obvious implementation would have a va_list be a pointer to the stack frame of
the variadic function. In such a setup (by far the most common) there seems noth‐
ing against an assignment
va_list aq = ap;
Unfortunately, there are also systems that make it an array of pointers (of length
1), and there one needs
va_list aq;
*aq = *ap;
Finally, on systems where arguments are passed in registers, it may be necessary
for va_start() to allocate memory, store the arguments there, and also an indica‐
tion of which argument is next, so that va_arg() can step through the list. Now
va_end() can free the allocated memory again. To accommodate this situation, C99
adds a macro va_copy(), so that the above assignment can be replaced by
va_list aq;
va_copy(aq, ap);
...
va_end(aq);
Each invocation of va_copy() must be matched by a corresponding invocation of
va_end() in the same function. Some systems that do not supply va_copy() have
__va_copy instead, since that was the name used in the draft proposal.
CONFORMING TO
The va_start(), va_arg(), and va_end() macros conform to C89. C99 defines the
va_copy() macro.
[quote="randi"][quote="Chris"]These changes aren't BSD-specific, but are more for cleaning away older-styled code (malloc.h is deprecated, fmod.h shouldn't be included in non-fmod code, __va_copy is an internal function/replaced by va_copy in C99, kill() needs signal.h).[/quote]
The manpages I read indicated you needed to include malloc.h to get malloc_usable_size. Is this no longer the case? Malloc.h is also listed as a [url=http://msdn.microsoft.com/en-us/library/6ewkz86d.aspx]required header[/url] for VC++. Is malloc.h really deprecated, or is FreeBSD overly critical?[/quote]
Probably a bit of both. I don't know why a system would flat-out throw an error over using an old header instead of just a warning. My Linux manpages don't seem to have malloc_usable_size, although the page for malloc says stdlib.h.
However, it seems you're right. Including stdlib.h instead of malloc.h doesn't give malloc_usable_size. Interesting. http://www.slac.stanford.edu/comp/unix/package/rtems/doc/html/libc/libc.info.malloc.html says it's under stdlib.h, but it also says "`malloc_usable_size' is not portable." so I would expect some issues there regardless. I guess it would be best to leave m_alloc.cpp alone, then, until a CMake check is made to find which header it's in (can't say I'm in a hurry to do that).
[quote]I don't remember why I used __va_copy instead of va_copy, but I know there was a reason.[/quote]
Perhaps because va_copy is C99, but MinGW was stuck at GCC 3.4 which didn't have it? That would be my guess, anyway. My man pages say:
[code] va_copy()
An obvious implementation would have a va_list be a pointer to the stack frame of
the variadic function. In such a setup (by far the most common) there seems noth‐
ing against an assignment
va_list aq = ap;
Unfortunately, there are also systems that make it an array of pointers (of length
1), and there one needs
va_list aq;
*aq = *ap;
Finally, on systems where arguments are passed in registers, it may be necessary
for va_start() to allocate memory, store the arguments there, and also an indica‐
tion of which argument is next, so that va_arg() can step through the list. Now
va_end() can free the allocated memory again. To accommodate this situation, C99
adds a macro va_copy(), so that the above assignment can be replaced by
va_list aq;
va_copy(aq, ap);
...
va_end(aq);
Each invocation of va_copy() must be matched by a corresponding invocation of
va_end() in the same function. Some systems that do not supply va_copy() have
__va_copy instead, since that was the name used in the draft proposal.
CONFORMING TO
The va_start(), va_arg(), and va_end() macros conform to C89. C99 defines the
va_copy() macro.[/code]