[3/3] include/aout/aout64.h: guard ARCH_SIZE with defined()

  Silence -Wundef when ARCH_SIZE is not defined by checking that it is
defined before comparing its value.

Signed-off-by: Andrew Hanson <andrew@andrewhanson.dev>
---
 include/aout/aout64.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On 14.09.2025 21:52, Andrew Hanson wrote:
> Silence -Wundef when ARCH_SIZE is not defined by checking that it is
> defined before comparing its value.
> 
> Signed-off-by: Andrew Hanson <andrew@andrewhanson.dev>

Oh, interesting - there is an S-o-b here. Why not on the earlier two
patches?

> --- a/include/aout/aout64.h
> +++ b/include/aout/aout64.h
> @@ -43,7 +43,7 @@ struct external_exec
>  
>  /* Magic numbers for a.out files.  */
>  
> -#if ARCH_SIZE==64
> +#if defined(ARCH_SIZE) && ARCH_SIZE == 64
>  #define OMAGIC 0x1001		/* Code indicating object file.  */
>  #define ZMAGIC 0x1002		/* Code indicating demand-paged executable.  */
>  #define NMAGIC 0x1003		/* Code indicating pure executable.  */

I'm not quite sure here. Yes, what you do fits what happens if the
compiler silently uses 0 as value when it's undefined. I wonder
though whether the #else not kicking in when ARCH_SIZE isn't defined
wouldn't be better. Largely depends on how the file is used right
now, i.e. how much fallout there would be.

Jan
  

On Mon, Sep 15, 2025 at 05:03:15AM +0200, Jan Beulich wrote:
> Yes, what you do fits what happens if the
> compiler silently uses 0 as value when it's undefined.

It must.  See ISO/IEC 9899:1999 (E) 6.10.1 para 3.  Correct programs
do not need to write "#if defined(X) && X" except to silence the
warning.  Plain "#if X" is fine.

This isn't to say I oppose the patch.  Fussing over warnings is OK
too.  ;-)
  

On 15.09.2025 06:26, Andrew Hanson wrote:
> Sorry about the missing sign-offs on the first two patches. I'm still getting used to the tooling.

Btw, please also don't reply privately; keep the list in Cc.

> I agree the question about if the else block should trigger or not is complicated. I would be tempted to just keep the previous behavior regarding the else statement because I don't know enough about the project to know the downstream effects. 
> 
> It would almost certainly be worth adding a warning for the user if ARCH_SIZE is undefined. It might also make sense to discuss deprecating the “undefined -> 32-bit” fallback but I don’t feel comfortable making that call.

Okay, so let's go with what you had sent.

Jan
  

> Okay, so let's go with what you had sent.

That sounds good, thanks.

I did do a bit of digging regarding that else block. Atleast these four files (bfd/aout-ns32k.c, bfd/aout-target.h, bfd/aoutx.h, bfd/ecoff.c) include aout/aout64.h and use the 32 magic numbers (OMAGIC 0407, NMAGIC 0410, IMAGIC 0411, ZMAGIC 0413, QMAGIC 0314, BMAGIC 0415) without checking ARCH_SIZE, so they likely depend on the current behavior. Just FYI.

On Monday, September 15th, 2025 at 10:21 AM, Jan Beulich <jbeulich@suse.com> wrote:

> On 15.09.2025 06:26, Andrew Hanson wrote:
>
> > Sorry about the missing sign-offs on the first two patches. I'm still getting used to the tooling.
>
>
> Btw, please also don't reply privately; keep the list in Cc.
>
> > I agree the question about if the else block should trigger or not is complicated. I would be tempted to just keep the previous behavior regarding the else statement because I don't know enough about the project to know the downstream effects.
> >
> > It would almost certainly be worth adding a warning for the user if ARCH_SIZE is undefined. It might also make sense to discuss deprecating the “undefined -> 32-bit” fallback but I don’t feel comfortable making that call.
>
>
> Okay, so let's go with what you had sent.
>
> Jan