Re: encoding cleanups in cvs repo

I have cleaned up a couple of badly broken encodings in cvs commit
messages in:

src/backend/utils/error/Attic/exc.c,v

per discussion with Alvaro, by simply editing the RCS file directly in
the cvs repository. Only the commit message was changed (broken
character removed)

Should have no effect. In case something broke, I have extra backups :-)

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> I have cleaned up a couple of badly broken encodings in cvs commit
> messages in:

> src/backend/utils/error/Attic/exc.c,v

Out of curiosity ... what problems exactly? I just looked through my
last complete dump of CVS log history and didn't see anything funny
in the messages for exc.c ...

regards, tom lane

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> I have cleaned up a couple of badly broken encodings in cvs commit
>> messages in:
>
>> src/backend/utils/error/Attic/exc.c,v
>
> Out of curiosity ... what problems exactly? I just looked through my
> last complete dump of CVS log history and didn't see anything funny
> in the messages for exc.c ...

***************
*** 1337,1344 ****
log
@Avoiding
cc1: warnings being treated as errors
! exc.c: In function ^ExcRaise':
! exc.c:186: warning: passing arg 1 of ^Longjmp' from incompatible
pointer type
gmake[3]: *** [exc.o] Error 1

Now we have:
--- 1337,1344 ----
log
@Avoiding
cc1: warnings being treated as errors
! exc.c: In function 'ExcRaise':
! exc.c:186: warning: passing arg 1 of 'Longjmp' from incompatible
pointer type
gmake[3]: *** [exc.o] Error 1

That's the output from diff, which also doesn't properly recognise the
character, but it should give you a pointer where it is. (It's not just
the ^ character, that's what diff shows me for something else, obviously)

I think it's a "backtick" in some encoding.

//Magnus

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > I have cleaned up a couple of badly broken encodings in cvs commit
> > messages in:
>
> > src/backend/utils/error/Attic/exc.c,v
>
> Out of curiosity ... what problems exactly? I just looked through my
> last complete dump of CVS log history and didn't see anything funny
> in the messages for exc.c ...

It's rev 1.7 of that file -- it had a ^E and a ^L.

There was something funny in pgbench.c too, around 1.41 or something
like that.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Out of curiosity ... what problems exactly? I just looked through my
>> last complete dump of CVS log history and didn't see anything funny
>> in the messages for exc.c ...

> It's rev 1.7 of that file -- it had a ^E and a ^L.

Ah, I was looking for high-bit-set characters. Yeah, I see those.
The backtick is clearly the right thing if you compare to the adjacent
commit message for another branch.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane wrote:
> >> Out of curiosity ... what problems exactly? I just looked through my
> >> last complete dump of CVS log history and didn't see anything funny
> >> in the messages for exc.c ...
>
> > It's rev 1.7 of that file -- it had a ^E and a ^L.
>
> Ah, I was looking for high-bit-set characters.

Right, we have our share of those too, but Magnus is filtering them with
iconv or Python internal recoding routines, and they don't cause
problems. However those routines were not touching those control chars,
and later steps of the process were choking on them.

> Yeah, I see those. The backtick is clearly the right thing if you
> compare to the adjacent commit message for another branch.

Right, and it's the usual quoting rule used by FSF stuff (and others I
assume).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.