On Sun, Apr 6, 2008 at 9:20 PM, Mark Glines via RT <[EMAIL PROTECTED]> wrote:
> Ok, thanks for the clarification. How do you think we should fix it? The patch I submitted for this ticket earlier addresses the multiple redefinitions issue without doing anything funny with the PARROT_HAS_SNPRINTF macro and family. However, mine might not be the best solution to it. As I understand it, the logic is: 1) If PARROT_HAS_SNPRINTF is defined, the system has a native snprintf definition, and no new macro needs to be created. 2) If PARROT_HAS_C99_SNPRINTF is defined, define snprintf to use Parrot_secret_snprintf instead. Originally, and this was not changed in my patch, PARROT_HAS_C99_SNPRINTF and PARROT_HAS_SNPRINTF are both defined, the C99 one takes precidence, and Parrot_secret_snprintf is used instead of the native snprintf. This might be worth changing. 3) If _MSC_VER is defined, we use the MS-specific _snprintf function instead. In this case, it is unlikely that we have a native snprintf implementation, and it is also unlikely that we want to use Parrot_secret_snprintf instead of _snprintf. Actually, now that I think about it, let me go back and redo the patch that I submitted to be more comprehensive. I'll post it as soon as I have something that makes sense. --Andrew Whitworth
