[AVR] : Use tr instead of set to canonicalize line endings for cmp

This patch replaces sed with tr when t-avr checks for
consistency between generated doc/avr-mmcu.texi and the compiler.

The method is the same as used in s-tm-texi in gcc/Makefile.in

The problem was reported by Joerg. Does it work for you?

Ok for trunk?

Johann

	* config/avr/t-avr: Correct avr-mmcu.texi dependencies.
	(s-avr-mmcu-texi): Use tr instead of sed to factor out line endings.

As Georg-Johann Lay wrote:

> The problem was reported by Joerg. Does it work for you?

Yes, it works fine.

> +	case `echo X|tr X '\101'` in 					\
> +	  A) tr -d '\015' < tmp-avr-mmcu.texi > tmp2-avr-mmcu.texi ;; 	\
> +	  *) tr -d '\r' < tmp-avr-mmcu.texi > tmp2-avr-mmcu.texi ;; 	\
> +	esac

I don't think it has to be that complicated.  Using octal notation has
already been supported by V7 UNIX's tr(1) command, and it is
standardized by the Single Unix Specification (SUSp, formerly POSIX)
as well.  SUSp also standardizes \r, but as this is not mentioned in
the V7 manual, I don't know exactly when this had been introduced, so
I'd go for \015 being the most portable way.  The above decision would
thus always decide for this option anyway.

On 05/30/2012 05:17 AM, Georg-Johann Lay wrote:
> +# The avr-mmcu.texi we want to compare against / check into svn should
> +# have unix-style line endings.  To make this work on MinGW, remove \r.
> +# \r is not portable to Solaris tr, therefore we have a special case
> +# for ASCII.  We use \r for other encodings like EBCDIC.
>   s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext)
> -	$(RUN_GEN) ./$<  | sed -e 's:\r::g'>  avr-mmcu.texi
> +	$(RUN_GEN) ./$<  >  tmp-avr-mmcu.texi
> +	case `echo X|tr X '\101'` in 					\
> +	  A) tr -d '\015'<  tmp-avr-mmcu.texi>  tmp2-avr-mmcu.texi ;; 	\
> +	  *) tr -d '\r'<  tmp-avr-mmcu.texi>  tmp2-avr-mmcu.texi ;; 	\
> +	esac

Why not do this inside gen-avr-mmcu-texi.c instead?

Instead of writing to stdout, open the file to write, and open
it in binary mode.  Seems much easier than fighting with conversion
after the fact.


r~

As Richard Henderson wrote:

> Instead of writing to stdout, open the file to write, and open
> it in binary mode.  Seems much easier than fighting with conversion
> after the fact.

(Disclaimer: I'm not the author.)

There has been an argument that (some) older implementations might not
be able to handle the "b" for binary mode.  It's probably questionable
whether such ancient (Unix) implementations bear any relevance anymore
when it comes to the AVR port of GCC though.  (IIRC, ISO-C90 did
standardize the "b" mode letter to fopen().)

On 05/30/2012 05:44 PM, Joerg Wunsch wrote:

> As Richard Henderson wrote:
> 
>> Instead of writing to stdout, open the file to write, and open
>> it in binary mode.  Seems much easier than fighting with conversion
>> after the fact.
> 
> (Disclaimer: I'm not the author.)
> 
> There has been an argument that (some) older implementations might not
> be able to handle the "b" for binary mode.  It's probably questionable
> whether such ancient (Unix) implementations bear any relevance anymore
> when it comes to the AVR port of GCC though.  (IIRC, ISO-C90 did
> standardize the "b" mode letter to fopen().)


Not 'fopen' with "b", but 'open' with O_BINARY.  There's precedent for that
already in gcc and other parts of the toolchain (binutils, gdb), as a grep
will tell.  O_BINARY is defaulted to 0 in system.h (so that it's a nop), and
is usually defined in fcntl.h (to non-zero) on platforms that actually
differentiate text and binary modes, such as Windows.

On 05/30/2012 10:26 PM, Pedro Alves wrote:

> On 05/30/2012 05:44 PM, Joerg Wunsch wrote:
> 
>> As Richard Henderson wrote:
>>
>>> Instead of writing to stdout, open the file to write, and open
>>> it in binary mode.  Seems much easier than fighting with conversion
>>> after the fact.
>>
>> (Disclaimer: I'm not the author.)
>>
>> There has been an argument that (some) older implementations might not
>> be able to handle the "b" for binary mode.  It's probably questionable
>> whether such ancient (Unix) implementations bear any relevance anymore
>> when it comes to the AVR port of GCC though.  (IIRC, ISO-C90 did
>> standardize the "b" mode letter to fopen().)
> 
> 
> Not 'fopen' with "b", but 'open' with O_BINARY.  There's precedent for that
> already in gcc and other parts of the toolchain (binutils, gdb), as a grep
> will tell.  O_BINARY is defaulted to 0 in system.h (so that it's a nop), and
> is usually defined in fcntl.h (to non-zero) on platforms that actually
> differentiate text and binary modes, such as Windows.
> 


Oh, and BTW, include/ in the src tree has these fopen-bin.h, fopen-same.h and
fopen-vms.h headers (*), that you could import into the gcc tree, and use if you
want to stick with fopen and friends.  They provide a series of defines
like FOPEN_RB, FOPEN_WB, etc., to map to "r", "w", or "rb", "wb", etc. depending
on host.  This is used all over binutils whenever it wants to fopen files in binary
mode.  If it's fine for binutils, it should be fine for gcc.  You'd might
also want something like this <http://sourceware.org/ml/binutils/2012-05/msg00227.html>
to reuse bfd's configury to pick the one to use (and perhaps add a wrapping
fopen-foo.h header).

(*) -
 http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/include/fopen-bin.h?rev=1.1.1.1&content-type=text/plain&cvsroot=src
 http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/include/fopen-same.h?rev=1.1&content-type=text/plain&cvsroot=src
 http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/include/fopen-vms.h?rev=1.3&content-type=text/plain&cvsroot=src