Thread: 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@hagander.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@hagander.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@hagander.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@commandprompt.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@commandprompt.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.