[ProgClub list] Memory management in C

John Elliot jj5 at progclub.org
Sun Oct 2 04:11:18 AEDT 2011

On 1/10/2011 11:25 PM, jedd wrote:
>   But .. I agree.  I don't think they could have been that hard
>   or else I wouldn't have been able to understand them.

You should give yourself more credit dude. :P

>> 90% of what who needs to know for what? I haven't followed you man.
>   90% of what you need to know about C (to learn the language
>   proper I mean) could be gained from K&R.  With the earlier caveat
>   (analysing other people's code) of course.
>   Didn't the second edition of K&R cover ANSI C?  (quick check).  Ahh,
>   they were basing it on the ANSI proposal.
>   I suspect I never got into it sufficiently to care about the
>   distinctions between the two variants.

Ah, when you were referring to "K&R" you were referring to the book, not 
the C dialect. There were two version of the book (as you know), one was 
for the K&R dialect (the first version) and the second was targeted at 
ANSI C (or as you point out, a late proposal).

I agree that the K&R book is a great book. It's slim and terse and tells 
you just about everything you need to know. (Except to stress how 
seriously you should check you're not about to overflow a buffer).

>   No, probably not.  At least not without some other glue.  Perhaps
>   as a method of yakking to the socket - though it'd be a lot less
>   fun, and probably just as much work ultimately.

On that, I've learned something from my tinkering. Well, kinda learned 
something but more kinda discovered a problem I can't quite account for.

I invoke telnet to talk to my service at the moment with something like:

  $ echo command-name | telnet localhost 1337

The thing is, this exits before printing the server's response. I think 
it's because the *client* is tearing down the connection before the 
server does. Also, the telnet command prints a whole heap of gunk about 
the escape character and its connection status which there doesn't seem 
to be a "quiet" mode to turn off. So... I think I'm going to write two 
commands, one called 'pcad' for running the server and the other called 
'admin-request' to send commands to the server. So to send an admin 
request it will be:

  $ admin-request command-name

And then I can parse the server response and exit with a proper error 
level. I.e. non-zero on command failure.

>> Yeah, that's cool. I'll setup a pcad user and add it to the sudo group,
>> which will give it the permission it needs to read the particular files
>> I need it to (i.e. the file that contains the password for the MySQL
>> root user). Still, don't you need to supply your password when you
>> invoke sudo? I didn't want to create a user that had to know its password.
>   Hmm.  Not sure.  I'd suggest a web search for dropping privileges
>   the polite way.  It's not something I've ever done, sorry, so I can't
>   offer any insight there.

Haven't understood what you mean by "dropping privileges the polite 
way". I think I'm going to follow Stuart's advice and set up my sudoers 
file so that the password is not required (and only the listed commands 
are allowed).

>   If you're thinking about turning this into a .deb you may want to
>   consider using the debian-sys-maint account (/etc/mysql/debian.cnf)
>   rather than root.  I tend to not use a password on my mysql root
>   account on most of my systems (but these are not systems that
>   I share with untrusted users).

Yeah, using the debian-sys-maint account for the MySQL stuff might be a 
good idea. Might look into that down the track.

I would *love* to set this up as a .deb so that I could publish a URL 
that you include in your sources.list file, but I have nfi how to do 
that... yet. Definitely something I'd like to look into. But I'll wait 
'til I've got the application suite developed first. Can't go putting 
the horse before the cart.

>> Basically user accounts start at 1000, and utility accounts start at
>> 500. That should keep out of the way of the Debian standard users/groups
>> shouldn't it?
>   This seems to fit within the Debian policy (section 9.2.2) (refer to
>   http://www.debian.org/doc/debian-policy/ch-opersys.html ) though it
>   sounds like you should be doing this dynamically on installation
>   using adduser --system rather than picking a number and using it
>   everywhere.  (Just in case that's what you were thinking of doing.)

Ah, hadn't heard of adduser --system, I'll have to look into that. Thanks!

More information about the list mailing list