Should attachments be accepted in comp.lang.c?

[Keith Thompson]

Recently a poster here posted some C code as an attachment.

Should attachments (text only) be considered acceptable in this
newsgroup?

I don't recall the subject even coming up until just a few days ago.
Almost everyone here posts C code as plain inline text.

I think we can agree that binary attachments are inappropriate. But
what about text-only attachments? It's argued that newsreaders that
don't handle attachments will display them as plain inline text, and
those that do will handle them in some convenient manner.

In fact, it appears that a text attachment in a posted article is
represented as approximately 4 header lines, followed by the content
of the attachment, followed by 1 trailer line. (I determined this by
grabbing a copy of the orginal article in question using a small Perl
script and the NNTP protocol, rather than via a newsreader; I expect
that a newsreader that doesn't understand attachments would simply
display the extra lines along with the content.)

Personally, I tend to prefer inline text rather than attachments, even
for multiple chunks of code. If I want to try compiling a posted
piece of code, I copy it from the window in which I'm reading news,
then paste it into a window on the machine where I want to compile it.
If I had to save the attachment to do this, I'd have to copy the
resulting file from one machine to another; not impossible, of course,
but inconvenient enough that I often wouldn't bother. Of course,
others will have different preferences.

I'll offer one data point. I read news using Gnus, a newsreader that
runs under GNU Emacs. It handles attachments reasonable well; the
file name is displayed in bold text, and the attachment is expanded
inline after I move the cursor on top of it and press <enter>. (Note
that I'm referring to a text cursor, not a mouse cursor, so moving it
to the right spot can require several keystrokes.) I presume there's
command to save the attachment as a file, but I haven't bothered to
find out. As I said, I prefer inline text to attachments, but I can
deal with them if there's a consensus that they're acceptable. If
there are people using newsreaders that make plain-text attachments
difficult to handle, I suggest that attachments should be discouraged.

This was discussed recently in the "passing a union's field to a
function" thread, particularly in the "Posting sample C-code as
attachment" subthread. There was some disagreement about whether any
conclusion had been reached. I thought it would be useful to have
this discussion in its own thread.

 

[Dik T. Winter]

> Recently a poster here posted some C code as an attachment.
>
> Should attachments (text only) be considered acceptable in this
> newsgroup?

I think not. If you want text to be seen by all, you should put it in the
main article. Text only newsreaders (like mine) will just display it as
part of the main body of the article, with some surrouding nonsense (and
after the signature, so they may skip it).
Text only newsreaders that are aware of attachments (like yours) will not
show it, but ask you for a place to store it. And that place can be
quite inconvenient, as it is possibly not in a place where you have
access to a compiler.

 

[Ian Collins]

I think not. If you want text to be seen by all, you should put it in the
main article. Text only newsreaders (like mine) will just display it as
part of the main body of the article, with some surrouding nonsense (and
after the signature, so they may skip it).
Text only newsreaders that are aware of attachments (like yours) will not
show it, but ask you for a place to store it. And that place can be
quite inconvenient, as it is possibly not in a place where you have
access to a compiler.

According to Keith, Gnus does show the attachment.

Are there any text only newsreaders in uses that don't either inline
attachments, or provide a means to view them?

I'm ambivalent on the subject, my newsreader shows attachments inline.

 

[Walter Roberson]

Recently a poster here posted some C code as an attachment.

Should attachments (text only) be considered acceptable in this
newsgroup?

In my opinion, NO.

I think we can agree that binary attachments are inappropriate. But
what about text-only attachments? It's argued that newsreaders that
don't handle attachments will display them as plain inline text, and
those that do will handle them in some convenient manner.

No MIME. It gives my newsreader indigestion if I allow my newsreader
to process it, and it gives -me- indigestion if I don't allow my
newsreader to process it.

The order of the attachments is not fixed by the MIME standards,
by the way, so clients are free to (and some well-known ones *will*)
sometimes put the attachments first and -then- the message.

 

[Robert Gamble]

Recently a poster here posted some C code as an attachment.

Should attachments (text only) be considered acceptable in this
newsgroup?

I don't think so. I can think of absolutely no benefit from allowing
attachments but plenty of reasons not to:

- It is inconvenient for me to have to download an attachment
seperately and I (and I suspect many others) would be considerably less
likely to take the time to do so than I would if the code in question
were presented inline. I use 3 different newreaders (including Google
Groups) and only one of them seems to automatically embed the contents
of attachments inline (and not always very well), it also happens to be
the one I use the least.

- If the encoding of the attached file does not match the encoding used
on the system in which the file is detached and read there can be
issues, this doesn't occur with inline text since the newsreader
presents the text in the native encoding. For example, the attachment
in the post you mentioned was apparently created on a *nix machine and
didn't display properly on my Windows machine. I have to either
convert the line-feeds to carriage return + line feeds or open the file
with a program that does this automatically. If I wasn't discouraged
from reading attachments before, I am now.

- If legitimate messages can contain attachments, I can't tell my
newsreader to not download articles that contain attachments assuming
they are Spam, or rather I still can but I will just never see the
articles in question.

- Allowing attachments certainly won't help encourage people to post
*small* examples, when people realize it is just as easy to attach a
20K file as it is a 2K file and it doesn't make the post *look* any
larger, many won't be as hesitant to do so.

- Many news servers have a very long retention of text-only newsgroups
because the amount of storage required to keep the articles on the
server is minimal. Allowing attachments could greatly increase the
amount of space required to do so and as a result retention among
servers may decrease.

Is it any more difficult for someone to post the code inline than to
post it as an attachment? What would be the proposed benefit from
allowing attachments?

Robert Gamble

 

[Ronald Bruck]

Recently a poster here posted some C code as an attachment.

Should attachments (text only) be considered acceptable in this
newsgroup?

I don't recall the subject even coming up until just a few days ago.
Almost everyone here posts C code as plain inline text.

I think we can agree that binary attachments are inappropriate. But
what about text-only attachments? It's argued that newsreaders that
don't handle attachments will display them as plain inline text, and
those that do will handle them in some convenient manner.

MY newsreader (Thoth, running under Mac OS X 10.47) didn't show the
attachments as either attachments OR as embedded text. I saw nothing
AT ALL.

I checked the article on a couple of different news servers, just to be
sure it wasn't my news server which was censoring them. And I set the
"View" mode to "Show Details". Nada.

I believe the main objections to attachments are: size; and viruses.
The former is no worse than putting them inline; the latter is
irrelevant for text attachments (unless you're stupid enough to read
them with Microsoft Word).

Allowing text attachments is probably "the lesser of two weevils". But
be aware, not everybody may be able to read them.

BTW, how do you distinguish between text and binary attachments?

 

[Keith Thompson]

BTW, how do you distinguish between text and binary attachments?

If we were going to decide that text attachments are acceptable and
binary attachments are not, then I suppose the distinction would be
that text attachments are those that are still legible (with extra
header and footer lines) when displayed by a newsreader that ignores
attachments.

The header lines for the attachment that started this discussion were:

Content-Type: text/x-csrc; name="union.c"
Content-Transfer-Encoding: 8Bit
Content-Disposition: attachment; filename="union.c"

I suppose the Content_Type starting with "text/" is indicative -- but
then again there are different kinds of text.

 

[Len Philpot]

MY newsreader (Thoth, running under Mac OS X 10.47) didn't show the
attachments as either attachments OR as embedded text. I saw nothing
AT ALL.

Simply another data point (FWIW, since I'm definitely a lurker here in
read-only mode) --

The newsreader I'm using now, 40tude Dialog / WinXP, displays all
attachments as well as a raw view in a menu adjacent to the
(attachment-less) article body. That allows the reader to see the
article body sans attachments, the attachments individually and the
whole thing togther inline.

As far as any other platforms go, I don't recall offhand how tin handles
things, as it's been a while since I had either a Linux or Solaris box
at home.

So for me, it doesn't really matter. Maybe the additional info will help
somehow.

 

[CBFalconer]

Recently a poster here posted some C code as an attachment.

Should attachments (text only) be considered acceptable in this
newsgroup?

No.

Various systems will automatically strip attachments from news
posts, or even totally suppress the post.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

 

[Mikhail Teterin]

This was discussed recently in the "passing a union's field to a
function" thread, particularly in the "Posting sample C-code as
attachment" subthread. There was some disagreement about whether any
conclusion had been reached. I thought it would be useful to have
this discussion in its own thread.

You may also start another thread on the subject:

Should everyone be *forced* to post in the same manner?

Because I don't see, how your troubles (or lack thereof) are supposed to
compell *me*. My postings are on-topic of the news-group, and so are the
attachements.

I'm at a loss over this desire for uniformity, you are displaying...

While I'm here, let me quickly go over the objections raised so far:

* Various systems will automatically strip attachments from news
posts, or even totally suppress the post.

That's a problem with those "various systems". A poster, aware of the issue,
may still attach C-code to postings, hurting no one, but him/herself.

* It is inconvenient for me to have to download an attachment

That's a reason for *you* not to bother, but not a reason to ban such posts.

* If the encoding of the attached file does not match the encoding
used on the system in which the file is detached and read there can be

Converting the plain text between platforms' EOL representation is a trivial
excercise. All text-editors, that come with compilers (including vim and
emacs) are smart enough to automatically detect the proper EOL format,
while the good old `vi' can strip Windows' Ctrl-M in one short command.

Posting in-line and copy/pasting is likelier to introduce subtle problems
and is guaranteed to make code-review difficult (references to line-numbers
are off).

* If legitimate messages can contain attachments, I can't tell my

Are you REALLY willing to through MIME away, because spammers abuse it? Come
on -- have the "spammer already won"?

* Allowing attachments certainly won't help encourage people to post

Uhh, place a maximum size limit, then. This is silly...

* Text only newsreaders that are aware of attachments will not
show it, but ask you for a place to store it. And that place can be
quite inconvenient, as it is possibly not in a place where you have
access to a compiler.

A MIME-aware newsreader, that does not offer to show the attachment as plain
text (especially, if the type is set to text/*) is broken...

Really and trully, all complete files (rather than illustratory segments)
should be placed on a web-site by the poster, posting just a link, IMO

Soon, when everyone gets their own web-server, we'll be able to make this a
requirement. This will save space/bandwidth AND allow post-posting
corrections of the C-code.

-mi

 

[Andrew Poelstra]

Is it any more difficult for someone to post the code inline than to
post it as an attachment? What would be the proposed benefit from
allowing attachments?

I believe that it's more difficult for me to post the code inline (using
vi's :read command) than it is to attach a file (using slrn's attachment
feature, which is one keystroke after posting the file.)

Also, it's easier to compile code that's in its own neat little package,
without text surrounding it. I don't have copy and paste on my terminal
(if I do, I don't know how to use it), so this would be simpler than
1) Saving the message
2) Switching ttys to edit saved file
3) Hacking out the headers/message/signature portion of file
4) Compile with output piped to a temp file
5) Return to first tty to reply
6) Typing :read /tmp/compile_output to post the output.

Having an attached file would save the 3rd step, which is the majority
of the work.


Having said all that, my newsreader displays attachments inline, so it's
a moot point for me and I have no opinion.

 

[Andrew Poelstra]

You may also start another thread on the subject:

Should everyone be *forced* to post in the same manner?

Because I don't see, how your troubles (or lack thereof) are supposed to
compell *me*. My postings are on-topic of the news-group, and so are the
attachements.

The newsgroup is here to help you. It is your right to make it difficult
or not worth it for us to help, but then again, it's also your right to
shoot yourself in the foot. Have fun with that.

I'm at a loss over this desire for uniformity, you are displaying...

While I'm here, let me quickly go over the objections raised so far:

* Various systems will automatically strip attachments from news
posts, or even totally suppress the post.

That's a problem with those "various systems". A poster, aware of the issue,
may still attach C-code to postings, hurting no one, but him/herself.

Ah, so we should switch newservers, readers, platforms, proxies, and/or
locations? Being as most of those aren't possible or desirable in most
circumstances, eliminating the problem through conformance doesn't seem
such such a big deal.

* It is inconvenient for me to have to download an attachment

That's a reason for *you* not to bother, but not a reason to ban such posts.

It's a reason to frown upon such posts; your argument can also be used
to support top-posting, incomprehensible W3bSpeak, and OT questions.

* If the encoding of the attached file does not match the encoding
used on the system in which the file is detached and read there can be

Converting the plain text between platforms' EOL representation is a trivial
excercise. All text-editors, that come with compilers (including vim and
emacs) are smart enough to automatically detect the proper EOL format,
while the good old `vi' can strip Windows' Ctrl-M in one short command.

Posting in-line and copy/pasting is likelier to introduce subtle problems
and is guaranteed to make code-review difficult (references to line-numbers
are off).

1) Even if it's simple, it's still a pain to convert.
2) What should those of us reading newsgroups on a mainframe?

(Answer to #2: Stop, drop, and roll.)

* If legitimate messages can contain attachments, I can't tell my

Are you REALLY willing to through MIME away, because spammers abuse it? Come
on -- have the "spammer already won"?

Really OT: Have you seen ING Direct's new security system? Yes, the
spammers and phishers appear to have "won". It's best not to think
about it.

* Allowing attachments certainly won't help encourage people to post

Uhh, place a maximum size limit, then. This is silly...

Still a pain and an inconvience.

* Text only newsreaders that are aware of attachments will not
show it, but ask you for a place to store it. And that place can be
quite inconvenient, as it is possibly not in a place where you have
access to a compiler.

Really and trully, all complete files (rather than illustratory segments)
should be placed on a web-site by the poster, posting just a link, IMO

Many people do that. It works pretty well; one line, no headers, easy to
ignore, quick to load off the newserver...

Soon, when everyone gets their own web-server, we'll be able to make this a
requirement. This will save space/bandwidth AND allow post-posting
corrections of the C-code.

No, it's still much more convienient to post inline code. I'd need to log
into a new terminal to read a web page, and I'd have to memorize the URL
because I don't know how to transfer text across ttys.

 

[Keith Thompson]

You may also start another thread on the subject:

Should everyone be *forced* to post in the same manner?

Feel free to start such a thread if you like. I won't, because the
answer is obviously no.

This is an unmoderated newsgroup; nobody is forced to do, or not to
do, anything. We have a general (but not universal) consensus about
what is and is not considered appropriate here, but we have no
enforcement mechanism other than persuasion and killfiles.

If you haven't read it already, I recommend

Because I don't see, how your troubles (or lack thereof) are supposed to
compell *me*. My postings are on-topic of the news-group, and so are the
attachements.

Great. Topicality isn't the only issue.

If you posted text whose lines are alternately 20 and 110 characters
long, you would get complaints regardless of its topicality, because
it would be difficult to read. Most likely nobody would complain to
your ISP or set up a cancelbot, but some people would probably start
to ignore our posts, and others might even killfile you.

As we've seen in this thread, attachments cause real problems for real
people.

I'm at a loss over this desire for uniformity, you are displaying...

It's not so much a desire for uniformity as a lack of desire for
variation for its own sake. Posting code samples inline has worked
very well here for decades. If attachments were better, I wouldn't
object.

While I'm here, let me quickly go over the objections raised so far:

* Various systems will automatically strip attachments from news
posts, or even totally suppress the post.

That's a problem with those "various systems". A poster, aware of the issue,
may still attach C-code to postings, hurting no one, but him/herself.

* It is inconvenient for me to have to download an attachment

That's a reason for *you* not to bother, but not a reason to ban
such posts.

Again, nobody is suggesting banning anything. But if you ask for
help, I'm at a loss to understand why you'd want to make things more
difficult for (some of) the people who are otherwise willing and able
to help you.

* If the encoding of the attached file does not match the
encoding used on the system in which the file is detached
and read there can be

Converting the plain text between platforms' EOL representation is a trivial
excercise. All text-editors, that come with compilers (including vim and
emacs) are smart enough to automatically detect the proper EOL format,
while the good old `vi' can strip Windows' Ctrl-M in one short command.

It's an additional step that you're forcing (some of) your readers to
take.

Posting in-line and copy/pasting is likelier to introduce subtle
problems and is guaranteed to make code-review difficult (references
to line-numbers are off).

* If legitimate messages can contain attachments, I can't tell my

Are you REALLY willing to through MIME away, because spammers abuse it? Come
on -- have the "spammer already won"?

I'm willing to avoid using MIME in a discussion newsgroup like this
one.

* Allowing attachments certainly won't help encourage people to post

Uhh, place a maximum size limit, then. This is silly...

* Text only newsreaders that are aware of attachments will
not show it, but ask you for a place to store it. And that
place can be quite inconvenient, as it is possibly not in a
place where you have access to a compiler.

A MIME-aware newsreader, that does not offer to show the attachment as plain
text (especially, if the type is set to text/*) is broken...

Some people here apparently use such newsreaders. They work perfectly
until people start posting attachments.

Really and trully, all complete files (rather than illustratory segments)
should be placed on a web-site by the poster, posting just a link, IMO

Posting links is just fine; people do it here all the time.

 

[Mark F. Haigh]

I believe that it's more difficult for me to post the code inline (using
vi's :read command) than it is to attach a file (using slrn's attachment
feature, which is one keystroke after posting the file.)

Also, it's easier to compile code that's in its own neat little package,
without text surrounding it. I don't have copy and paste on my terminal
(if I do, I don't know how to use it), so this would be simpler than
1) Saving the message
2) Switching ttys to edit saved file
3) Hacking out the headers/message/signature portion of file
4) Compile with output piped to a temp file
5) Return to first tty to reply
6) Typing :read /tmp/compile_output to post the output.

Having an attached file would save the 3rd step, which is the majority
of the work.

<snippage>

I appreciate what you're saying. However, I think a root issue is a
dichotomy of philosophies. Many see the group as primarily a literary
medium-- a well-spoken matching of wits followed by a gradual
devolution into a flamewar, with intellectual proceeds going to charity
(aka the OP). Attachments are simply more noise in an already faint
signal. On the other hand, many don't see what all the fuss is about.

I'm firmly in the first group. There's a subtle and simple brutality
to the 72-column gridiron. I have to deal with
pathologically-formatted code daily. Why would I want to open
somebody's most-likely fubar-ed attachment? It seems like a kind of
sadomasochism to me.

As an aside, for your situation, throw the code's line range into a
file, then compile and read the result at the same time with a
':r!your_script_name' or something. Sheesh.

Mark F. Haigh
(e-mail address removed)

 

[Skarmander]

Walter Roberson wrote:

The order of the attachments is not fixed by the MIME standards,
by the way, so clients are free to (and some well-known ones *will*)
sometimes put the attachments first and -then- the message.

Not true. "The primary subtype for multipart, 'mixed', is intended for use
when the body parts are independent and need to be bundled *in a particular
order*." --RFC 2046 [Emphasis mine.] "As with 'multipart/mixed', the order
of body parts is significant." (on "multipart/alternative"). The same is in
the earlier RFC 1521.

The same applies to "multipart/digest", though that's not relevant here;
only "multipart/parallel" doesn't have significant order, but that is
inherent to the semantics.

Clients that mess up the order on reading are plain wrong, although it's
true that the RFC could be more explicit about this; "mixed" and
"independent body parts" don't imply "mix it up". Clients may mess up the
order on *composing* a message, but that's a quality of interface issue;
presumably they ought to send parts in the order they were attached, with
the main message first.

All that said, it is doubtlessly true that there are many poor MIME
implementations around.

S.

 

[Mark F. Haigh]

Mikhail Teterin wrote:

Because I don't see, how your troubles (or lack thereof) are supposed to
compell *me*. My postings are on-topic of the news-group, and so are the
attachements.

I'm at a loss over this desire for uniformity, you are displaying...

I love how you go from that to this:

Soon, when everyone gets their own web-server, we'll be able to make this a
requirement.

Nicely done. Are you part of ERT's extended family or something?


Mark F. Haigh
(e-mail address removed)

 

[jaysome]

Walter Roberson wrote:

The order of the attachments is not fixed by the MIME standards,
by the way, so clients are free to (and some well-known ones *will*)
sometimes put the attachments first and -then- the message.

Not true. "The primary subtype for multipart, 'mixed', is intended for use
when the body parts are independent and need to be bundled *in a particular
order*." --RFC 2046 [Emphasis mine.] "As with 'multipart/mixed', the order
of body parts is significant." (on "multipart/alternative"). The same is in
the earlier RFC 1521.

The same applies to "multipart/digest", though that's not relevant here;
only "multipart/parallel" doesn't have significant order, but that is
inherent to the semantics.

Clients that mess up the order on reading are plain wrong, although it's
true that the RFC could be more explicit about this; "mixed" and
"independent body parts" don't imply "mix it up". Clients may mess up the
order on *composing* a message, but that's a quality of interface issue;

^^^^^^^^^^^^^^^^^^^^
I think you meant, "quality of implementation"? Kinda like the
Standard C system() function:

system(cmd);/* may be implemeneted as {return 0;}

presumably they ought to send parts in the order they were attached, with
the main message first.

All that said, it is doubtlessly true that there are many poor MIME
implementations around.

All that said, by any account, clients that don't work--unlike the
client Forte Agent that does work running on Microsoft Windows XP
--with attachments are plain broken.

 

[Richard Tobin]

In fact, it appears that a text attachment in a posted article is
represented as approximately 4 header lines, followed by the content
of the attachment, followed by 1 trailer line.

Unfortunately that's only one of several ways of attaching text. It
may instead be base-64 encoded (much like uuencoding) or encoded so as
to preserve various characters while leaving much of the text
unchanged. On one mailing list I subscribe to, many messages are
unreadable without decoding even though they could perfectly well be
sent as plain text.

-- Richard

 

[Skarmander]

Walter Roberson wrote:

The order of the attachments is not fixed by the MIME standards,
by the way, so clients are free to (and some well-known ones *will*)
sometimes put the attachments first and -then- the message.

Not true. "The primary subtype for multipart, 'mixed', is intended for use
when the body parts are independent and need to be bundled *in a particular
order*." --RFC 2046 [Emphasis mine.] "As with 'multipart/mixed', the order
of body parts is significant." (on "multipart/alternative"). The same is in
the earlier RFC 1521.

The same applies to "multipart/digest", though that's not relevant here;
only "multipart/parallel" doesn't have significant order, but that is
inherent to the semantics.

Clients that mess up the order on reading are plain wrong, although it's
true that the RFC could be more explicit about this; "mixed" and
"independent body parts" don't imply "mix it up". Clients may mess up the
order on *composing* a message, but that's a quality of interface issue;

^^^^^^^^^^^^^^^^^^^^
I think you meant, "quality of implementation"? Kinda like the
Standard C system() function:

system(cmd);/* may be implemeneted as {return 0;}

Well, I was alluding to it, but it's not quite the same thing. A client has
to send attachments in the proper order, quality or no, but the manner in
which to specify this order is, eh, unspecified. The interface may not offer
or even imply an order in parts.

S.

 

[CBFalconer]

Keith Thompson wrote:
.... snip ...

While I'm here, let me quickly go over the objections raised so far:

* Various systems will automatically strip attachments from news
posts, or even totally suppress the post.

That's a problem with those "various systems". A poster, aware of
the issue, may still attach C-code to postings, hurting no one, but
him/herself.

Those "systems" are the ones that are propagating usenet around the
world, not the individual readers.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943