Re: [rfa] Change line to long

[Kevin Buettner <kevinb at cygnus dot com>]

On Feb 1, 11:07am, Andrew Cagney wrote:

> (more sparc64 -Werror fallout)
> 
> This was triggered by some realy nasty code in os9kread.c.  It was
> casting a pointer down to an integer (sizeof(long) == sizeof(void*) ==
> 32 and sizeof(int) == 16 right? :-).
> 
> The patch changes the type of symtab's line to long (from int) and then
> propogates that through the most obvious places.  The os9k read then
> casts that pointer across to slightly less non-portable long.  Given the
> os9k is probably on its last legs I can't see a good reason to try and
> clean up that chunk code.
> 
> The alternative quick hack is to cast (void*) -> (long) -> (int) and
> change the assert to check that sizeof(void*) <= sizeof(int) ...
> 
> Look ok? Comments?

Changing the type of ``line'' to long is probably a good idea anyway,
but the code which calls record_line() in os9kread.c just looks wrong
to me.  I guess I'd prefer to see this bit of code in os9kread.c
done correctly, but if it really is on its last legs, then perhaps
it's not worth it.  You might want to poke around www.microware.com
for a minute or two to verify that it's really on its last legs.  (I
used os9k not too long ago.)

Now that you've made me look, another bit that looks just plain wrong
to me is the following code from record_line() in buildsym.c:

  if (line == 0xffff)
    {
      return;
    }

What happens if we're debugging a file that has more than 65535 lines
in it?  (I'm not saying that your patch should address this problem,
but it something for the maintainer(s) of this file to make note of
and clean up at some point.)

Anyway, back to your patch...

I notice in dwarf2read.c and dwarfread.c that an unsigned long is
being passed to record_line().  Is there any reason not to make the
type of ``line'' an unsigned long?

Kevin