ANSI strings, comment style, ...

ANSI strings, comment style, ...

[Doug Evans]

I'm working on adding this patch, but a few comments.

You're using ANSI C facilities to stop strings from running past
80 columns.  Someone correct me if I'm wrong but I believe
that's a no-no.  [Is it written down somewhere what, if any,
of ANSI C facilities one can use for GAS?  Should we set a timeframe for
when we'll start allowing such things?]

Also, I couldn't find a passage in the GNU coding conventions that explicitly
says so, but I think it's prefered that one write comments like this:

void
foo ()
{
  /* this is variable a, blah blah blah */
  int a;
  /* this is variable b, blah blah blah */
  int b;
  /* this is variable c, blah blah blah */
  int c;

   ...
}

rather than this:

void
foo ()
{
  int a;   /* this is variable a, blah blah blah */
  int b;   /* this is variable b, blah blah blah */
  int c;   /* this is variable c, blah blah blah */

   ...
}

[i.e. write comments on a line by themselves, above what they refer to,
rather than beside]

I've applied your commenting changes as is [the ones that reduce the
column width] but you may wish to switch over instead.

Mon Oct 27 21:44:30 1997  Ian Dall  <Ian.Dall@dsto.defence.gov.au>

	* write.h (struct fix): comment fx_pcrel_adjust field.

	* write.c (print_fixup): Use TC_FIX_DATA_PRINT (if defined) to
	print out MD fields of fix.

	* frags.c (frag_var, frag_variant): Use TC_FRAG_INIT macro (if
 	defined) to initialize MD fields in frag.

	* doc/internals.texi (Frags): document fr_opcode_frag and
 	fr_opcode_offset fields. Documetn TC_PCREL_ADJUST macro.

	* config/tc-ns32k.h: Add comments. Remove obsolete
 	BFD_FAST_SECTION_FILL definition, change prototypes for
 	fix_new_ns32k and fix_new_ns32k_exp to add new arguments
 	opcode_frag and opcode_offset and remove
 	pcrel_adjust. (TC_FIX_TYPE): add opcode_fragP and opcode_offset
 	fields.
	(TC_FIX_DATA_PRINT): new macro to print out TC_FIX_TYPE.
	(TC_FRAG_INIT): new macro to initialize machine dependent field in
 	frags.
	(frag_opcode_frag, frag_opcode_offset, frag_bsr): macros to access
 	MD fields in frag structure.
	(fix_im_disp, fix_bit_fixP, fix_opcode_frag, fix_opcode_offset,
 	fix_bsr): macros to access MD fields in fix structure.

	* config/tc-ns32k.c: Avoid overlength lines. Align comments.  Don't
 	use struct opcode_location as these fields are now in the frag
 	structure. (convert_iif): Call frag_more as it is needed instead
 	of trying to allocate for the whole insn. Avoid call of frag_more
 	with negative argument. (md_pcrel_adjust, md_fix_pcrel_adjust,
 	md_apply_fix, md_estimate_size_before_relax, md_pcrel_from,
 	tc_aout_fix_to_chars): use accessor macros to get md fields in fix
 	and frag structures. (fix_new_ns32k, fix_new_ns32k_exp): add new
 	arguments opcode_frag and opcode_offset and remove pcrel_adjust.
	(convert_iif, cons_fix_new_ns32k): call fix_new_ns32k,
 	fix_new_ns32k_exp with changed arguments.

	* as.h: Move fragS typdef to before struct frag definition.
	Remove ns32k frag substructure and add fr_ns32k substructure.

Re: ANSI strings, comment style, ...

[Ian Lance Taylor]

   Date: Tue, 4 Nov 1997 15:38:12 -0800
   From: Doug Evans <devans@cygnus.com>

   You're using ANSI C facilities to stop strings from running past
   80 columns.  Someone correct me if I'm wrong but I believe
   that's a no-no.  [Is it written down somewhere what, if any,
   of ANSI C facilities one can use for GAS?  Should we set a timeframe for
   when we'll start allowing such things?]

gas and the binutils are, of course, a special case, because they may
be required to bootstrap the compiler.  My inclination is to never
permit ANSI C features.  Or, to be slightly more reasonable, let's say
not for the next five years.

Ian

Re: ANSI strings, comment style, ...

[Ian Lance Taylor]

   Date: Wed, 5 Nov 1997 11:10:31 +1030
   From: Ian Dall <Ian.Dall@dsto.defence.gov.au>

   To be honest I was not sure this was new in ANSI. We are not talking
   about cpp "#" and "##" operations. What I think we are talking about
   is writing:

		     printf("A very long string. Warning: unacceptable argument to %s instruction", insn);

   as

		     printf("A very long string."
			    "Warning: unacceptable argument to %s instruction\n",
			     insn);


Yes, that sort of string concatenation is new in ANSI.

   If this is not acceptable, what is the preferred way to do this? I'd
   sooner not make it two printf's and I think

		     printf("A very long string.\
   Warning: unacceptable argument to %s instruction\n", insn);

   Is almost as ugly as just letting the line wrap.

I say, let the line wrap.  If it really bugs you, initialize a
variable and print that.

Note that you need a space between the `printf' and the open
parenthesis in your example.  In your first example, you can, and
should, put ``insn'' on the next line.

Ian

Re: ANSI strings, comment style, ...

[Ian Dall]

Ian Lance Taylor <ian@cygnus.com> writes:

  >    Date: Tue, 4 Nov 1997 15:38:12 -0800
  >    From: Doug Evans <devans@cygnus.com>

  >    You're using ANSI C facilities to stop strings from running past
  >    80 columns.  Someone correct me if I'm wrong but I believe
  >    that's a no-no.  [Is it written down somewhere what, if any,
  >    of ANSI C facilities one can use for GAS?  Should we set a timeframe for
  >    when we'll start allowing such things?]

  > gas and the binutils are, of course, a special case, because they may
  > be required to bootstrap the compiler.  My inclination is to never
  > permit ANSI C features.

To be honest I was not sure this was new in ANSI. We are not talking
about cpp "#" and "##" operations. What I think we are talking about
is writing:

                  printf("A very long string. Warning: unacceptable argument to %s instruction", insn);

as

                  printf("A very long string."
                         "Warning: unacceptable argument to %s instruction\n",
                          insn);

If this is not acceptable, what is the preferred way to do this? I'd
sooner not make it two printf's and I think

                  printf("A very long string.\
Warning: unacceptable argument to %s instruction\n", insn);

Is almost as ugly as just letting the line wrap.

Ian