Re: [RFA/hpux] Implement file_matches_executable_p

[Joel Brobecker <brobecker at adacore dot com>]

> 2005-11-17  Joel Brobecker  <brobecker@adacore.com>
> 
>         * corefile.c (generic_core_file_matches_executable_p): New function.
>         * libbfd-in.h (generic_core_file_matches_executable_p): Add
>         declaration.
>         * libbfd.h: Regenerate.
>         * hpux-core.c: ANSIfy function declarations and prototypes.
>         (thread_section_p): Manually expand bfd_section_name macro
>         to make it clear that parameter ABFD is not used.
>         (hpux_core_core_file_matches_executable_p): Delete, replaced
>         by macro pointing to generic_core_file_matches_executable_p.

Commenting on my own code...

> +  exec = bfd_get_filename (exec_bfd);
> +  last_slash = strrchr (exec, '/');
> +  if (last_slash != NULL)
> +    exec = last_slash + 1;
> +  
> +  /* The cast below is to avoid a compiler warning due to the assignment
> +     of the const char * returned by bfd_core_file_failing_command to a
> +     non-const char *.  In this case, the assignement does not lead to
> +     breaking the const, as we're only reading the string.  */
> +     
> +  core = (char *) bfd_core_file_failing_command (core_bfd);
> +  last_slash = strrchr (core, '/');
> +  if (last_slash != NULL)
> +    core = last_slash + 1;
> +
> +  return (strcmp(exec, core) == 0);

I would suggest two modifications:

  1. Revert the order, and compute core first. If we can't
     get a name (ie get NULL), then return immediately.
     Return which value though? I think we should return 0,
     but this may cause warnings in GDB that weren't there
     before. I do expect that most of the time, the user will
     be using the correct core file, but I think it's better
     to warn when we're not sure.

  2. I think I need to add some guards against a null core.
     I looked at a draft of the C90 standard, and it doesn't
     say how well it reacts to a null string... Should I also
     do the same for exec? I don't think that bfd_get_filename
     can ever return a null string, right?

I thought about the above while working on replacing the stubbed
instances of core_file_matches_executable_p...

-- 
Joel