RFC: PR 31964: Add .base64 pseudo-op to gas

[Jan Beulich]

On 10.07.2024 13:27, Nick Clifton wrote:
>> The doc addition presently suggests that only one or two strings can
>> be supplied, due to there not being any use of @dots{}. 
> 
> Oops - sorry about that.
> 
>> further wonder
>> in how far it is necessary to require comma separated arguments. This
>> is because of me observing, in the doc change, that e.g. .ascii and
>> .asciz don't require commas as separators.
> 
> Actually they do, although this is not indicated in their one-line description
> in the menu section of the document.

I'm confused now, since ...

>> Requiring commas certainly
>> has positive aspects (see my scrubber work to deal with e.g. macro
>> arguments not having such a requirement), so the question is mainly wrt
>> possible concerns towards overall consistency.
> 
> I think that the patch is being consistent with commas.  The place where it
> is inconsistent is in the handling of multiple double quote enclosed strings
> which are not separated by commas.  For example:
> 
>    .asciz "hello" "world"
>    .base64 "hello" "world"
> 
> The .ascii directive will be accepted and will produce a single zero-terminated
> string "helloworld".

... here you confirm they don't. The comma is optional there. But anyway,
that's secondary here.

>  Whereas the .base64 directive will reject the input, saying
> that there is junk at the end of the line, starting with the third double quote
> character.
> 
> To be honest, I prefer this behaviour for the .base64 pseido-op.  It keeps the
> code simple, and since we are not dealing with human-readable strings, the need
> for compatibility with the behaviour of string handling in C compilers is not
> there.  (At least in my opinion).

Fair enough. I merely thought I'd point out a possible inconsistency.

Jan