Ask Your Question

libstdc++ source code

asked 2012-10-16 19:12:21 -0500

Mohan G gravatar image


In my C program, I am having problems with strcpy() function on Fedora-16. The same code works as expected on Fedora-13. Also, it works fine with my own strcpy() implementation. So, I would like to look into the source code of this strcpy() function on those two fedora versions.

On Fedora 16: Name : libstdc++ Arch : i686 Version : 4.6.3 Release : 2.fc16

On Fedora-13: Name : libstdc++ Arch : i686 Version : 4.4.5 Release : 2.fc13

Can anyone tell how can I get the source code that is installed in F-16 & F-13.


edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2012-10-18 10:13:11 -0500

dmalcolm gravatar image

updated 2012-10-18 10:13:54 -0500

The easiest way to see the source code that you're actually running from is to install the relevant debuginfo package, via debuginfo-install (part of the yum-utils package).

"strcpy" is actually implemented as part of glibc

# debuginfo-install glibc

Then look below /usr/src/debug.

strcpy is something of a special case. Given how commonly it occurs, it's a prime target for optimization. Looking at this on my F17 machine I see that the header files that declare strcpy also have a tangled web of preprocessor macros cases that can turn a call to strcpy into a more specialized function, depending on whether the source string is a string-literal of known size, and, if so, the length of that string.

To make things even more convoluted, note that strcpy is a prime target for compiler optimization, and that at any given callsite of strcpy the compiler might not have generated machine code that calls strcpy if it thinks it can do things faster. For example, looking at the sources of gcc on my F17 machine, I see in gcc/builtins.c:expand_builtin_strcpy that if gcc sees a "strcpy" call it can instead generate a movstr instruction when targetting CPUs that support it.

So it's worth invoking the compiler with -E to see the preprocessed output, and disassembling the generated machine code to see if strcpy is actually being called (e.g. by stepping through it in gdb and using the disassemble command within the function of interest).

edit flag offensive delete link more

answered 2012-10-19 20:42:14 -0500

mattdm gravatar image

There's a handy program called yumdownloader installed as part of the yum-utils package. You probably have this on your system already, but if not, yum -y install yum-utils.

Then, run:

yumdownloader --source libstdc++

and you'll get the source RPM for that package. Unpack that (another topic in itself, if you've not done that before, make that another question), and you'll have the source plus any Fedora-applied patches.

Alternately, every package should contain the URL of the project from which that code came. You can get this by running

yum info libstdc++

and looking on the URL line. In this case, that points to, and you should be able to find the source there.

edit flag offensive delete link more

answered 2012-10-19 19:28:01 -0500

I have done a lot ow work in c++. the string copy works under ideal conditions, and the cell you are copying has to have room to spare. I found the NULL termination to be unreliable, so now I use the following. .for(I=0;I<80;I++) {output[I] = input[I]} This will always copy a fixed length string, and will always work. Have fun.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2012-10-16 19:12:21 -0500

Seen: 1,099 times

Last updated: Oct 19 '12