Portable int?

[BruceS]

I know enough to know that I don't know everything. I am well aware of
the things I could accidentally do if I ran as root. If I knew more, I
wouldn't do those things even if I ran as root...

Yes. IME, those who know Unix well recognize that they don't know
everything, are very careful about being root, and know that fat fingers can
be a problem even when not root but are worse as root. Too many of those who
don't know Unix well often run as root, because they can "do anything"
without permission complaints.
I once saw a coworker attempt to restart inetd. He first got its pid, say
32, then typed something like "kill 1 32". He was surprised when the machine
went to single-user mode.

 

[Sheldon Simms]

tombox root # gcc -O2 -Wall -W --std=c99 -pedantic -c test.c
^^^^^^

<OT> Shame on you! </OT>

He'll learn. Sooner or later, they all do. Of course, it'll cost him
half a dozen years' worth of files, but hey, who cares about porn JPEGs
and C source which voids main()?

How so?

Go ahead and break into apache. You will get my website [provided you can
do it]. That's the only server I'm running. I build all my programs from
scratch. I do weekly backups, um... whatelse...

I thought Richard was predicting that sooner or later, you're going to
do it to yourself, no Apache cracking needed. I'm not brave enough to
do development from root.

Hey maybe he's running Lindows. Doesn't it default to running everything
as root?

 

[Dan Pop]

Oddly enough, that sounds very much like the behavior of those who *do* know
a lot about Unix.

The more you know about Unix the more you realise how easy it is to shoot
yourself in the foot by having more privileges than strictly needed for
the job...

I like a sharp tool when I need one, but I put it back in its sheath
as soon as I'm done with it.

Dan

 

[Alex]

I run gentoo and the only server I have [apache] runs as user/group
apache....

What is your point again?

Oh yeah, stupid ass lame script kiddie comment about how l33t you are.

Uh.

Obviously you entirely failed to grasp my point. Doing development
as root is idiotic, not because of script kiddies but because of what
you, yourself, will accidentally do sooner or later.


Alex

 

[David M. Wilson]

How so?

Go ahead and break into apache. You will get my website [provided you can
do it]. That's the only server I'm running.

Don't you mean TSR, Tom?

I build all my programs from scratch.

In this day and age, that makes you a very incompetant manager.

I do weekly backups, um... whatelse...

oh yeah, you're an ass who doesn't know jack f'ing squat.

Tom

cc -o mirror mirror.c

If only C were a more expressive language, and you were worth it, I'd
come up with a better quip.


David.

 

[Joona I Palaste]

Yes. IME, those who know Unix well recognize that they don't know
everything, are very careful about being root, and know that fat fingers can
be a problem even when not root but are worse as root. Too many of those who
don't know Unix well often run as root, because they can "do anything"
without permission complaints.
I once saw a coworker attempt to restart inetd. He first got its pid, say
32, then typed something like "kill 1 32". He was surprised when the machine
went to single-user mode.

I've always wondered what would happen if I killed process 1, init. What
causes the computer to react to this? The kernel itself? I take it the
kernel doesn't have a process id, but is instead always running,
incapable of being killed?

 

[August Derleth]

I don't know very much about Unix.

There are people here who do know plenty about Unix who agree with you
on your statement below.

Therefore I always run as non-root unless
I have a special reason to run as root.

And that classes you with those who /do/ know a lot about Unix, as
well as the more clueful among those who know a good bit about Unix.
Doing routine stuff as root is pretty risky and classes you as a
rather clueless newbie or a clue-resistant moron. Both kinds of people
are just waiting to be smacked down by their own ignorance.

 

[Richard Heathfield]

He'll learn. Sooner or later, they all do. Of course, it'll cost him
half a dozen years' worth of files, but hey, who cares about porn JPEGs
and C source which voids main()?

I don't know anything about TSD's taste in JPEGs, but I'm fairly sure he
knows that main() returns int.

 

[Mark McIntyre]

How so?

you seem to be logged in as root. Sooner or later you'll slip up and
accidentally rm -R /*

oh yeah, you're an ass who doesn't know jack f'ing squat.

Idiots running as root should not drop glass bricks.

 

[Minti]

I was nodding my head and agreeing with you right up
until that final [remark]. Would you mind explaining just
what it is "we all know," because I can't figure it out.
What's an "array expression," and what has it to do with
the int-ness of anything?

When an expression is used to index an array...e.g.

int *p;

p[(some expression)] = (some other expression);

The expression on the left has to [technically] evaluate to an integer "int"
data type. I'm fairly certain it's a rule but I couldn't quote you the
section/page num of it.

The expression on the left has to evaluate to a 'lvalue'. In case you
are asking the type of some_expression then that would be size_t which
is obviously some integer type guranteed to hold the size of any
object.

 

[Minti]

I'm just curious, why don't we just use uint8_t or uint16_t for example
to declare an integer type storage when we know int is always
platform-dependent?

Are these the types provided by standard C.

 

[Mark McIntyre]

On 13 Nov 2003 15:00:40 -0800, in comp.lang.c ,

Are these the types provided by standard C.

They're required to exist if the platform supports objects of that
size. Otherwise they're required /not/ to exist. This means that you
can safely use them in portable code, since it either
a) compiles and works as expected or
b) doesn't even compile

 

[Kelsey Bjarnason]

[snips]

In this day and age, that makes you a very incompetant manager.

If it's in opposition to using possibly unsafe precompiled binaries, it
doesn't. Starting with a minimal base system from a trusted source, then
building the rest from examinable (and, presumably, examined) sources -
strikes me as a theoretically good thing; just time consuming and
expensive.

 

[Peter Nilsson]

On 13 Nov 2003 15:00:40 -0800, in comp.lang.c ,


They're required to exist if the platform supports objects of that
size.

They are only required if the *implementation* defines an integer type
(standard or extended) with the properties needed for a given intN_t.

For example, an MC680x0 implementation could choose not to define a
16-bit integer type, even though it is supportable by the underlying
chipset.

Otherwise they're required /not/ to exist.

Well, int8_t and int16_t can't exist on implementations where CHAR_BIT
is not a multiple of 8, but appart from that, even a 1c or sm
implementation could mimic those integers under the 'as if' rule.

This means that you
can safely use them in portable code, since it either
a) compiles and works as expected or
b) doesn't even compile

By that definition, Windows programs are 'portable'.

 

[Richard Bos]

I don't know very much about Unix.

Clue != knowledge, and you're a good example of that.

Richard

 

[Richard Bos]

How so?

Go ahead and break into apache.

I don't need to. All I need to do is wait until you type rm -rf ./* and
slip on the period key.

oh yeah, you're an ass who doesn't know jack f'ing squat.

Right. And you, I expect, are a true professional, with no personal
problems except a somewhat limited vocabulary where invective is
concerned.

Richard

 

[Keith Thompson]

On 13 Nov 2003 15:00:40 -0800, in comp.lang.c ,


They're required to exist if the platform supports objects of that
size. Otherwise they're required /not/ to exist. This means that you
can safely use them in portable code, since it either
a) compiles and works as expected or
b) doesn't even compile

Note that uint8_t and friends are new in C99. Some C90
implementations may provide them as an extension (or you can define
them yourself, or grab Doug Gwyn's q8 library from
<http://www.lysator.liu.se/c/q8/>).

 

[Dan Pop]

I've always wondered what would happen if I killed process 1, init.

You can always try it. IIRC, the kernel will panic, but it may be
kernel specific.

What causes the computer to react to this? The kernel itself?

Isn't it obvious? How do you kill it? By asking the kernel to do it,
so the kernel knows that it is killing the init process. It is up to it
to decide how to react to such a request.

I take it the
kernel doesn't have a process id, but is instead always running,
incapable of being killed?

Even if it had a PID, how would you kill it, other than by asking itself
to commit suicide?

After creating the init process, the kernel goes into "passive" mode:
it merely reacts to interrupts, traps and service requests from the
processes.

Dan

 

[Joona I Palaste]

You can always try it. IIRC, the kernel will panic, but it may be
kernel specific.

I don't think I will, though. I'm fairly sure there would be no
permanent loss of data, but I would still have to reboot if the kernel
panics particularly nastily.

Isn't it obvious? How do you kill it? By asking the kernel to do it,
so the kernel knows that it is killing the init process. It is up to it
to decide how to react to such a request.

Hmm, so all kill signals go to the kernel, and not directly to the
process itself? It sort of makes sense. If they always went directly
to the process, then processes that ignored SIGKILL (signal number 9)
would be possible.

Even if it had a PID, how would you kill it, other than by asking itself
to commit suicide?

By asking itself to commit suicide, of course. That doesn't mean the
kernel will comply, though. But nothing would stop me from writing a
kernel that did comply - other than the fact that I don't know how to
write kernels.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I am not very happy acting pleased whenever prominent scientists overmagnify
intellectual enlightenment."
- Anon

 

[Dan Pop]

I don't think I will, though. I'm fairly sure there would be no
permanent loss of data, but I would still have to reboot if the kernel
panics particularly nastily.

Is this such a big deal?

Hmm, so all kill signals go to the kernel, and not directly to the
process itself?

All signals, regardless of type. The Unix system call used for this
purpose is called "kill", but it handles all signals, including 0,
which means no signal, but check if the calling process has the
rights to send signals to the destination process.

It sort of makes sense.

It makes a lot of sense, if you want to avoid chaos in the system.

If they always went directly
to the process, then processes that ignored SIGKILL (signal number 9)
would be possible.

SIGKILL is never delivered to the process: the kernel simply kills the
process, if it determines that it is OK to do so (the requester has
adequate rights and the process is in a state in which it can be safely
killed).

By asking itself to commit suicide, of course. That doesn't mean the
kernel will comply, though. But nothing would stop me from writing a
kernel that did comply - other than the fact that I don't know how to
write kernels.

Each kernel allows a process to ask it to commit suicide in two ways:
halt and reboot. Otherwise, there would be no way of rebooting or
shutting down a Unix system, without pressing a switch or a button ;-)

Dan