btoa generates wrong line breaks.

Assigned to


18 years ago
12 years ago


(Reporter: Wan-Teh Chang, Assigned: Wan-Teh Chang)


Windows 98

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
The 'btoa' command uses text-mode libc file I/O
functions to write to the output.  It calls the
NSSBase64 functions to do base64 encoding.  The
NSSBase64 encoding functions use CRLF (\r\n) as
line breaks.  When \r\n is passed to the text-mode
libc file output functions, we get
- \r\n on Unix;
- \r\r\n on Windows,
neither of which is the correct line break for
text files on that platform.

We can fix this in either of two ways:
1. Change btoa.c to use binary-mode libc file
   I/O functions to write to the output.  The
   output file will have \r\n line breaks on
   all platforms.
2. Change the NSSBase64 encoding functions in
   mozilla/security/nss/lib/util/nssb64e.c to
   use just \n as line breaks and let the
   text-mode libc file I/O functions in btoa.c
   translate \n to the correct native line
   breaks on that platform.

Which method to use depends on whether we want
to use \r\n or the platform native line break
on all platforms.

Comment 1

18 years ago
Created attachment 16750 [details] [diff] [review]
A patch to change btoa.c to use binary-mode libc file output.

Comment 2

18 years ago
I attached this patch first not because I
think it's a better solution but because it
is easier.

Comment 3

18 years ago
Ian, please let me know if this should be fixed
in 3.2 or can be deferred.  Thanks.
Target Milestone: --- → 3.2

Comment 4

18 years ago
According to RFC 1421, "To represent the encapsulated text of a PEM message, the
encoding function's output is delimited into text lines (using local
Thus, IMO the encoder should always use \n and not \r\n.  This change will
precipitate into many of the tools, as some use binary mode write (PR_Write).
Priority: P3 → P1

1. "local conventions" surely implies "the conventions of the local system".
For Unix, that's \n, for Macintosh that's \r, and for Windoze that's \r\n.
So, why should the encoder always use \n?

2. Do we care about conformance to the old PEM RFCs?

Comment 6

18 years ago
It was my understanding that \n's will be converted to \r\n's on Windoze, and
left alone on Unix, when using fwrite.  The problem is that the encoder always
produces \r\n's, which is fine if you always use binary mode, but problematic on
Windoze if using ascii mode, since the \r\n's will become \r\r\n's.  So there
are two solutions: change all the tools to use binary mode I/O, or change the
encoder.  I took that line in the PEM spec to mean that the encoder is what
should be changed.  Personally, I think the output from the encoder should be
suitable for ascii mode output, since users might not assume otherwise.

Comment 7

18 years ago
moving to future while we consider this more.
Target Milestone: 3.2 → Future

Comment 8

16 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
QA Contact: bishakhabanerjee → jason.m.reid
Obviously not P1 in any sense.
Assignee: bugz → wtchang
Priority: P1 → P4
Target Milestone: Future → ---
QA Contact: jason.m.reid → tools
You need to log in before you can comment on or make changes to this bug.