<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.c-programming">
    <title>gmane.linux.c-programming</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4297"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4296"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4295"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4294"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4293"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4292"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4291"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4290"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4289"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4289"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4287"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4285"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4284"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4283"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4282"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4281"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4280"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4279"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4278"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.c-programming/4277"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4297">
    <title>mq_timedreceive on multiple queues</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4297</link>
    <description>&lt;pre&gt;Hi,

I am currently facing an issue when reading in a set of several posix
queues (let's say 2 different mqueues) from several processes. I
currently use epoll_wait to wait for an incoming message on either
queue on all listening processes, then mq_timedreceive to retrieve it
from the queue.

This is an issue when the number of reader process grows, as if I send
only one message on a queue, all processes are awaken when epoll_wait
returns, and all processes try to fetch the message. I would like to
fix this and wake up only one process when listening to several
queues, removing the useless user/kernel space switchs for the other
listening processes.

Is there any way to run a mq_receive/mq_timedreceive on several
queues, that would wake up only one process? Something more or less
like epoll, but that also fetches a message from the readable queues
before returning.

Thanks,
Romain
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kern&lt;/pre&gt;</description>
    <dc:creator>Romain Geissler</dc:creator>
    <dc:date>2013-04-15T07:48:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4296">
    <title>Re: Sending and receiving packets from multiple lines</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4296</link>
    <description>&lt;pre&gt;
you can implement that your self of course but it probably would be better
to use channel bonding to do that and then send all the data over the bond
device and let the kernel take care of ordering issues - handling all the
corener cases of losing single lines, notably temporarily is a pain in the but.

Also with the use of bondign devices you get all the benifits of clean 
firewall and traffic control handling at kernel level - I doubt it is resonable
to handle this over multiple distinct lines in a meaningful way (with finite
effort that is...)

thx
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Nicholas Mc Guire</dc:creator>
    <dc:date>2013-03-24T10:58:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4295">
    <title>Re: Sending and receiving packets from multiple lines</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4295</link>
    <description>&lt;pre&gt;Hello,

TCP should reorder packet fragments.
If you're using UDP or a custom protocol over IP, you have absolutemy
no guarantee about the delivery of packets.

2013/3/23, Randi Botse &amp;lt;nightdecoder&amp;lt; at &amp;gt;gmail.com&amp;gt;:
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Celelibi</dc:creator>
    <dc:date>2013-03-23T16:42:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4294">
    <title>Sending and receiving packets from multiple lines</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4294</link>
    <description>&lt;pre&gt;Hi All,

My network implements interface bonding, aggregate several lines into
one logical line to achieve higher connection throughput and
redundancy.
I'm writing a network application in Linux that basically send packets
to another host outside. I got problem with packet ordering on
destination host, for example. packet1 from line1 should arrived
earlier than packet3 from line3, etc. I want them to be delivered in
correct order. Is this possible? if yes, what is the better way for
doing this?.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Randi Botse</dc:creator>
    <dc:date>2013-03-23T02:52:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4293">
    <title>Fwd: Your Photos</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4293</link>
    <description>&lt;pre&gt;Hi,
your photos as promised   http://www.jy118114.com/mail.htmN&lt;/pre&gt;</description>
    <dc:creator>Brandon Ojeda</dc:creator>
    <dc:date>2013-01-09T16:50:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4292">
    <title>Flood victims In Nigeria....Urgent Help needed</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4292</link>
    <description>&lt;pre&gt;Dear Friend, My name is Don Obi, we are flood victims in Nigeria and i need your help to help me save some funds in your country.....http://pmnewsnigeria.com/2012/10/12/flood-sacks-5-banks-in-bayelsa/     http://pmnewsnigeria.com/2012/10/12/jonathan-inspects-flood-ravaged-home-state-by-air/

don obi
+2348079731210



--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Don Obi</dc:creator>
    <dc:date>2012-10-13T12:23:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4291">
    <title>post try</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4291</link>
    <description>&lt;pre&gt;Please ignore. Sorry

&lt;/pre&gt;</description>
    <dc:creator>SL&lt; at &gt;maxis</dc:creator>
    <dc:date>2012-12-11T07:06:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4290">
    <title>Re: cat a /proc entry</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4290</link>
    <description>&lt;pre&gt;2012/11/21, ratheesh kannoth &amp;lt;ratheesh.ksz&amp;lt; at &amp;gt;gmail.com&amp;gt;:

Hello,

I'm not sure to understand your problem.
Do you write userland or kernelland code?
If you write kernel code, why don't you just use the API behind the
/proc file system?
If you write userland code, what is your problem with the buffer
allocation? You can allocate a buffer as big as your memroy allows it.


Celelibi
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Celelibi</dc:creator>
    <dc:date>2012-11-21T13:36:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4289">
    <title>cat a /proc entry</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4289</link>
    <description>&lt;pre&gt;Hi,

is there size limit on the buffer content as i am using  "cat" command
( so ,not allocating any buffer in userspace, so not doing any
copy_to_user from kernel; simply doing  sprintf(buffer, %s , data )
from kernel  for a big data  )

-Ratheesh
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>ratheesh kannoth</dc:creator>
    <dc:date>2012-11-21T04:04:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4289">
    <title>cat a /proc entry</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4289</link>
    <description>&lt;pre&gt;Hi,

is there size limit on the buffer content as i am using  "cat" command
( so ,not allocating any buffer in userspace, so not doing any
copy_to_user from kernel; simply doing  sprintf(buffer, %s , data )
from kernel  for a big data  )

-Ratheesh
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>ratheesh kannoth</dc:creator>
    <dc:date>2012-11-21T04:04:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4287">
    <title>Re: How does atomic operation work on smp</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4287</link>
    <description>&lt;pre&gt;

Atomic operations do not need to disable interrupts - a test-and-set operation does not disable interrupts. Locking primitives like spin-locks that allow you to get consistent access to non-atomic critical sections may disable interrupts.

It seems to me that you are identifying atomic operations with critical sections, which is not really the same thing - but maybe I missunderstood you.


More or less any (sane) architecture will provide some very basic atoicity
capabilities. a 32bit (or 64bit on 64bit boxes) data object is guaranteed
to be consistent (that is you will never be able to get half of the old and
half of the new value if there were a concurrent read and write). Some form
of Compare and Swap (CAS) / Test and Set bit assembler instructuion will be
provided that can overcome the lowest level race that would be incured by
setting and then testing in separate steps. And finally low level
mechanisms are provided to ensure consistency over cores by load/store
fences (memory barriers). 

In the above&lt;/pre&gt;</description>
    <dc:creator>Nicholas Mc Guire</dc:creator>
    <dc:date>2012-11-07T16:45:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4285">
    <title>How does atomic operation work on smp</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4285</link>
    <description>&lt;pre&gt;I understand how atomic operation work on unary core processors, I think it just disables the interrupt and dominate the cpu until it finished.
While, how do we implement this on multi processor computers?
Suppose cpu A is performing an atomic operation on variable a. At the same time, cpu B is also performing the operation on a. In such the result may be overwritten.
Of course we can use spinlocks, but on the atomic operation's behalf, how does it gurantee to prevent such case?
Can anyone explain the crux of it? Thanks.

Jimmy Pan
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Pan</dc:creator>
    <dc:date>2012-11-08T07:01:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4284">
    <title>Re: UDP message boundary</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4284</link>
    <description>&lt;pre&gt;This is very clear and complete answer.

Thanks You!

Regards.

On Sun, Oct 21, 2012 at 4:55 AM, Hendrik Visage &amp;lt;hvjunk&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Randi Botse</dc:creator>
    <dc:date>2012-10-21T09:46:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4283">
    <title>Re: UDP message boundary</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4283</link>
    <description>&lt;pre&gt;
TCP is like a water tap (a character device) that you need to "format"
yourself with boundaries/etc.


UDP is more like a block device, a letter/package sent. It's only the
single packet that is sent, and only that same single packet that will
be received (or go missing in the post)

I believe the error you might be refering to is  this one from a Linux
2.6 based Ubuntu 6.0.5 man page for recvfrom:

&amp;lt;quote man recv(2)&amp;gt;
       All  three  routines  return the length of the message on
successful completion.  If a message is too long to fit in the supâ
       plied buffer, excess bytes may be discarded depending on the
type of socket the message is received from.
&amp;lt;snip&amp;gt;
(recv(2) flags orred together:)
       MSG_TRUNC (since Linux 2.2)
              For  raw  (AF_PACKET),  Internet datagram (since Linux
2.4.27/2.6.8), and netlink (since Linux 2.6.22) sockets: return
              the real length of the packet or datagram, even when it
was longer than the passed buffer.  Not implemented  for  Unix
            &lt;/pre&gt;</description>
    <dc:creator>Hendrik Visage</dc:creator>
    <dc:date>2012-10-20T21:55:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4282">
    <title>Re: String formatting in signal handler</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4282</link>
    <description>&lt;pre&gt;2012/10/20, Randi Botse &amp;lt;nightdecoder&amp;lt; at &amp;gt;gmail.com&amp;gt;:


Hi,

You can only call safely system calls listed in man 7 signal. write is
one of them. So you can reimplement some snprintf and write it.
But I wouldn't recommend that for several reasons.
1) The most important thing is that you should not call any syscall
inside a signal handler because :
1.1) a syscall may be blocking and thus preventing your program to run
and to handle those signals
1.2) a syscall usually have side effects, which might create a race
condition with respect to the main program. Especially, it modify
errno, and your main program may be preempted just between a syscall
and a test to errno.
2) You may need a buffer to implement your formatting and cannot call
malloc nor brk.
3) You need a loop! If you receive several signal at the same time,
you get notified only once. There is no signal counter.

So, you may still do your processing inside the signal handler if you
take care of all these points (and thoses I forgot). But I would
recommend&lt;/pre&gt;</description>
    <dc:creator>Celelibi</dc:creator>
    <dc:date>2012-10-20T20:03:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4281">
    <title>String formatting in signal handler</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4281</link>
    <description>&lt;pre&gt;Hi List,

Almost (maybe all) function from the standard library stdio.h and
string.h are not safely to be called by signal handler. If so, how to
format string in a signal handler?. I want to log some signals which
sent to my program, the contents is for example: time, the signal
number itself, etc, and then write it to a file.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Randi Botse</dc:creator>
    <dc:date>2012-10-20T15:03:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4280">
    <title>Re: UDP message boundary</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4280</link>
    <description>&lt;pre&gt;Hi


Lorenzo: Yes, I already know what UDP socket is, I'm asking about UDP
message boundary behaviour.







--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Randi Botse</dc:creator>
    <dc:date>2012-10-19T15:03:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4279">
    <title>Re: UDP message boundary</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4279</link>
    <description>&lt;pre&gt;Almost:
1. udp is not reliable, so transmission may just fail
2. there's a maximum lenght of 64k (16 bit size counter)
3. ip fragmentation: as packet size grows, iirc one fragment lost means 
you loose everything

You can start from the wikipedia page and explore from that, or read the 
source of any program doing serious stuff with udp(*)


(*) there's an ftp alternative called fsp which uses udp, but I can't 
comment on the source code because I've never read it

--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Lorenzo Beretta</dc:creator>
    <dc:date>2012-10-19T14:15:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4278">
    <title>Re: UDP message boundary</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4278</link>
    <description>&lt;pre&gt;Anyone can share? :)

Thanks


On Mon, Oct 15, 2012 at 11:50 AM, Randi Botse &amp;lt;nightdecoder&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Randi Botse</dc:creator>
    <dc:date>2012-10-17T03:24:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4277">
    <title>UDP message boundary</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4277</link>
    <description>&lt;pre&gt;Hi All

When using TCP socket, I loop send() or recv() until ALL the data has
been transmitted (or error, disconnect, etc.), because TCP socket
packet is transmitted in stream nature, maybe a byte, bytes or all
bytes in one transfer.

The UDP socket preserve message boundary which TCP socket doesn't.
Does this means single call to sendto() will processed by single call
recvfrom()?, and how about packet that exceeds UDP data MAX size?.

So in code, do I need to loop sendto() or recvfrom() to transmit the data?.

Example codes is:

char packet[100];
size_t nbytes = 0;
int ret;

while (nbytes &amp;lt; sizeof(packet)) {
    ret = recvfrom(socket, packet + nbytes, addr, 0,  sizeof(packet) - nbytes);
    if (ret &amp;lt;= 0) {
        /* deal with recvfrom() error */
    }
    nbytes += ret
}


Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Randi Botse</dc:creator>
    <dc:date>2012-10-15T04:50:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.c-programming/4276">
    <title>Re: use getifaddrs()</title>
    <link>http://permalink.gmane.org/gmane.linux.c-programming/4276</link>
    <description>&lt;pre&gt;
Regular -- I'm not sure about getifaddrs, but most (all?) socket 
functions do the same, so sometimes (as in this case it sems) it's just 
assumed to be the default.
In general you can just check the manpage:
1. from your system -- "man getifaddrs"
2. from the posix std online
3. from www.freebsd.org -- its manpages section actually lets you look 
at manpages from a *lot* of unices (*BSD, linux, solaris, ...), it's 
very very handy

--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Lorenzo Beretta</dc:creator>
    <dc:date>2012-10-11T17:16:26</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.c-programming">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.c-programming</link>
  </textinput>
</rdf:RDF>
