Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 52897 - vsprintf, vsnprintf broken for AMD64
Summary: vsprintf, vsnprintf broken for AMD64
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: AMD64 Linux
: High major (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-03 10:27 UTC by Al Danial
Modified: 2004-06-03 18:53 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Al Danial 2004-06-03 10:27:53 UTC
A user on an Opteron system I administer discovered a problem with
vsprintf.  The system is running the AMD64 version of Gentoo 2004.1
(with multilib support).  C code to demonstrate the problem appears
below.  Correct output (produced for example on a P4 system running
RedHat Enterprise Workstation w/GCC 3.2.3, or on Sun or SGI workstations
running the vendors' commercial C compilers) is

 main. string: THIS IS A STRING
 len: 32, len1: 32
 main. string: THIS IS A STRING

while the 64 bit executable produced with GCC 3.3.3 on our
Gentoo-powered Opteron system produces

 main. string: THIS IS A STRING
 len: 32, len1: 21
 main. string: 4
Comment 1 Al Danial 2004-06-03 10:27:53 UTC
A user on an Opteron system I administer discovered a problem with
vsprintf.  The system is running the AMD64 version of Gentoo 2004.1
(with multilib support).  C code to demonstrate the problem appears
below.  Correct output (produced for example on a P4 system running
RedHat Enterprise Workstation w/GCC 3.2.3, or on Sun or SGI workstations
running the vendors' commercial C compilers) is

 main. string: THIS IS A STRING
 len: 32, len1: 32
 main. string: THIS IS A STRING

while the 64 bit executable produced with GCC 3.3.3 on our
Gentoo-powered Opteron system produces

 main. string: THIS IS A STRING
 len: 32, len1: 21
 main. string: 4öÿ¿

  -- Al

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
/* Demonstrate vsprintf() problem. Dale Williamson June 2 2004 */
 
#include <stdio.h>
#include <stdarg.h>
 
char GOUT[4096];
int gprintf(char *format, ...);
 
int main(int argc, char *argv[])
{
   return gprintf(" main. string: %s\n","THIS IS A STRING");
}
 
int gprintf(char *format, ...)
{
   int len,len1;
 
   va_list args;
   va_start(args,format);
 
   len=vfprintf(stdout,format,args);
 
   len1=vsprintf(GOUT,format,args);
   *(GOUT+len)='\0';
   fprintf(stdout," len: %d, len1: %d\n",len,len1);
 
   fprintf(stdout,"%s",GOUT);
 
   va_end(args);
   return len;
}
Comment 2 Al Danial 2004-06-03 11:36:08 UTC
The problem also affects 64 bit versions of RedHat using GCC 3.2 and 
3.4.  Thus it appears to be a generic problem with the 64 bit version 
of glibc.          -- Al
Comment 3 Danny van Dyk (RETIRED) gentoo-dev 2004-06-03 14:35:53 UTC
This is no bug, as you use the "args" twice without reinitialising them. It is clearly a bug to it like you do.

 len=vfprintf(stdout,format,args);
+va_end(args)
+va_start(format,args)
 len1=vsprintf(GOUT,format,args);

is the proper implementation.
Your code happens to work on x86, but it's clearly bogus to write C-Code like that, cause "args" is in an indefinite state after it is used.
Comment 4 Danny van Dyk (RETIRED) gentoo-dev 2004-06-03 14:40:17 UTC
sorry, s/va_start(format,args)/va_start(args,format)/
Comment 5 Al Danial 2004-06-03 18:53:13 UTC
My bad!  Thank you for the C programming lesson in any event.  -- Al