bfd: patch for missing strtoull

[Ian Lance Taylor]

Aldy Hernandez <aldyh@redhat.com> writes:

> On Fri, Jan 04, 2002 at 10:47:18AM -0800, Ian Lance Taylor wrote:
> 
> > No.  The right approach is to add strtoull to newlib.  (As far as I
> > can see, newlib has strtoul, but not strtoull.)
> 
> it seems it's already in there:
> 
> culebra:/source/uber/devo/newlib/libc/stdlib$ ls strtoull*.c
> strtoull.c  strtoull_r.c
> 
> i wonder why it's not getting linked...

I meant libiberty.  Sorry.

> > Or perhaps the code which uses strtoull should use bfd_scan_vma
> > instead.  The value appears to being stored in a bfd_vma, not in a
> > long long.
> 
> hmm, i don't know much about this bfd stuff.  the code is here (bfd/coff-rs6000.c)
> and it's the only place where strtoull is used in bfd, so an approach without
> strtoull would be better:
> 
> 	#define READ20(d, v) \
> 	  buff20[20] = 0, \
> 	  memcpy (buff20, (d), 20), \
> -->	  (v) = strtoull (buff20, (char **) NULL, 10)
> 
> 	static boolean
> 	xcoff_write_armap_big (abfd, elength, map, orl_count, stridx)
> 	...
> 	...
> 	  /* xcoff_write_archive_contents_big passes nextoff in symoff. */
> -->	  READ20 (fhdr->memoff, prevoff);
> -->	  READ20 (fhdr->symoff, nextoff);
> 
> do you suggest another approach?

Yes, change strtoull to bfd_scan_vma, if that's OK with Tom Rix.
While you're at it, eliminate the ``long long'' from PRINT20, and use
bfd_print_vma.  As far as I can tell from looking at the code for 20
seconds, that will always work.  I think the existing code is making
some unportable assumptions which are not appropriate for BFD.

Ian