[PATCH 4/8] BFD: Add BFD pointer member to `struct carsym'

[Jan Beulich]

On 17.10.2025 21:51, Maciej W. Rozycki wrote:
> On Fri, 17 Oct 2025, Jan Beulich wrote:
> 
>>> Replace the file offset with a union of one and a BFD pointer in `struct 
>>> carsym', as a preparation to handle symbol maps built on the fly rather 
>>> than fetched from a file.  No functional change.
>>>
>>> NB there's a note on `struct carsym' being a type pun on `struct symdef' 
>>> as in include/aout/ranlib.h (or `struct ranlib'; no idea where it comes 
>>> from).  With this code update in place it is possibly not true anymore, 
>>> depending on the underlying type of `file_ptr'.  This is not a problem 
>>> however, because we always process `struct carsym' data by hand and only 
>>> use it internally rather than reading/writing from/to a file.  Therefore 
>>> only remove the note, as no longer applicable.
>>
>> It wasn't quite true already before, as file_ptr != unsigned long (in the
>> general case).
> 
>  Yeah, also depending on the pointer size, owing to the `s.name' member of 
> `struct symdef'.  I guess I'll reword this as follows:
> 
> "
> NB there's a note on `struct carsym' being a type pun on `struct symdef' 
> as in include/aout/ranlib.h (or `struct ranlib'; no idea where it comes 
> from).  It is possibly not true anymore, even more so with this code 
> update in place, depending on the underlying type of `file_ptr'.  This 
> is not a problem however, because we always process `struct carsym' data 
> by hand and only use it internally rather than reading/writing from/to a 
> file.  Therefore remove the note, as no longer applicable.
> "

Sounds good. (I'd suggest s/possibly/generally/ though, or some such).

>>> --- binutils-gdb.orig/bfd/archive.c
>>> +++ binutils-gdb/bfd/archive.c
>>> @@ -149,12 +149,19 @@ extern int errno;
>>>  
>>>  /*
>>>  EXTERNAL
>>> +.{* Holds a file position or bfd* depending on context.  *}
>>> +.typedef union file_ptr_or_bfd
>>> +.{
>>> +.  file_ptr file_offset;
>>> +.  bfd *abfd;
>>> +.}
>>> +.file_ptr_or_bfd;
>>
>> The comment is too little for my taste, I'm afraid. How would one know which
>> of the two it is, merely seeing an instance of this type?
> 
>  It's up to the user of this data structure to decide, just as the comment 
> says.  Can you please elaborate what kind of description you'd like to see 
> here?

Hard to make a suggestion without knowing what, in at least an example
case, the approach to distinguish is. To take an abstract example: There
may be callback functions which want to take either kind of context data.
There it would be clear that the "scope" is strictly that between the
site setting up the data and the callback function. Since here you embed
the new type in another struct, it's less (if at all) clear.

>  FWIW an equivalent member of `struct orl' gone with 3/8 had yet a terser 
> description to the same effect and similarly there was no indication as to 
> which union member was to be used when.

Which doesn't really make it any better?

Jan