On Wed, Jun 22, 2016 at 12:35:22PM +0100, Simon Hobson wrote:
> Rainer Weikusat wrote:
> > Lastly, if the target system is Linux (as here), one can safely assume
> > that EBCDIC won't be used.
> >
> > None of this matter anyhow for solving algorithm exercises in an
> > entry-level book about a pr
On Wed, 22 Jun 2016 18:37:32 +0100, Katolaz wrote:
[...]
> It is perfectly legal in C to do something like:
>
> =
>
> int fun (int *v){
>
> v[4] = 17;
> }
>
> int fun2(char *p){
>
> p[32] = 0;
>
> }
>
> int fun3(float *f){
>
> f[7] = 3.1415;
> }
>
>
> int main(){
>
>
Simon Hobson writes:
> Rainer Weikusat wrote:
>> In absences of post hoc driver shuffling, these names *are not*
>> random.
[...]
> You've posted a statement that says drivers are loaded in a
> non-deterministic order. Therefore, in the general case where not all
> interfaces are using the same
On Wed, Jun 22, 2016 at 08:23:08PM +0200, Irrwahn wrote:
> On Wed, 22 Jun 2016 18:37:32 +0100, Katolaz wrote:
> [...]
> > no array can be actually "passed" to function,
> [...]
>
> I'm not trying to argue against anything you wrote in your
> spot-on analysis, but regarding that one claim quoted
Rainer Weikusat wrote:
> In absences of post hoc driver shuffling, these names *are not*
> random. But as that's clearly something you're not willing to believe
> in, this discussion seems pretty pointless.
I think we must be making assumptions about what each other are talking about -
you appe
--- Begin Message ---
On Tue, 2016-06-21 at 18:42 +0200, ItchyPirate wrote:
> policykit-1 requires libpam-systemd which in turn requires systemd . Since
> systemd is currently not available in Devuan, that makes policykit-1
> impossible to install. This is a big problem for for those of us with HP
KatolaZ writes:
[...]
> and the reason is that arrays in C are just syntactic sugar around
> memory addresses. This has nothing to do with polymorphism or generic
> programming, and is indeed much lower-level and more basic than
> that. Simply put, arrays do not effectively *exist* in C.
This i
Hi,
These are my worked examples. I am posting just in case some may want
to comment.
exercise1-17:
-
#include
#define MAXLINE 1000 /* maximum length of line */
int lgetline(char line[], int maxline);
/* print lines longer than 80 characters */
int main() {
int len;
Hi KatolaZ,
This reply was intended to you, but I mistakenly addressed it to Irrwahn. Sorry.
Edward
-- Forwarded message --
From: Irrwahn
Date: Wed, 22 Jun 2016 19:27:01 +0200
Subject: Re: [DNG] Studying C as told. (For help)
To: Edward Bartolo , irrwah...@freenet.de
Cc: dng@lis
On Wed, 22 Jun 2016 18:37:32 +0100, Katolaz wrote:
[...]
> no array can be actually "passed" to function,
[...]
I'm not trying to argue against anything you wrote in your
spot-on analysis, but regarding that one claim quoted above
one could postulate that an exception to that rule exists
for a
On Wed, Jun 22, 2016 at 05:04:38PM +0200, Edward Bartolo wrote:
[cut]
>
> This is why I am finding it hard to logically accept that "passing by
> reference" is NOT equivalent to passing a pointer for the machine. For
> the programmer, it is using a different syntax, but the machine sees
> no dif
On Wed, 22 Jun 2016 17:04:38 +0200, Edward Bartolo wrote:
> Hi,
>
> Irrwhan35 wrote:
> <<
> There is no "passing by reference" in C. Forget it. No
> references. Only *values*. Everything is passed *by* *value* in C. You
> will never pass "an array" to a function call in C. You will instead
> pass
On Wed, 22 Jun 2016 11:15:44 +0200
Edward Bartolo wrote:
> The program:
> --
> #include
>
> void times2(int i[]) {
> i[0] = 33;
> }
Others have commented on value and reference. What I have to add is
this: Always take special care to name functions and variables
desc
On Wed, 22 Jun 2016 14:08:55 +0200
Irrwahn wrote:
> On Wed, 22 Jun 2016 12:35:22 +0100, Simon Hobson wrote:
> > I suspect we've all conversed with people who have approximately
> > zero knowledge or interest in how "the greasy bits" of the machine
> > ends up running their code. My first compute
Simon Hobson writes:
> Rainer Weikusat wrote:
>>> If you just use the default kernel naming scheme then you open
>>> yourself to the problem that udev was designed to solve - that of
>>> random device names.
>>
>> If you'll neither believe me nor the code wrt causes these 'random
>> device names
W dniu 22.06.2016 o 08:20, KatolaZ pisze:
The easiest way is to have a cron script that runs once a day, with
root provileges, and calls "apt-get update". Then, your notifier could
be as simple as:
apt-get -s upgrade | grep "^[0-9]* upgr" | cut -d " " -f 1
which will give the number of package
I wrote:
>> Unless the admin transfers the installation to another system. Assuming
>> that everything used to work fine with eth0 - eth3, all hell will
>> break lose because the sole four interfaces are now called eth4 - eth7.
>
> But the point is, the admin can then, with one simple edit, retur
Rainer Weikusat wrote:
>> If you just use the default kernel naming scheme then you open
>> yourself to the problem that udev was designed to solve - that of
>> random device names.
>
> If you'll neither believe me nor the code wrt causes these 'random
> device names', may I try some kind of aut
Hi,
Irrwhan35 wrote:
<<
There is no "passing by reference" in C. Forget it. No
references. Only *values*. Everything is passed *by* *value* in C. You
will never pass "an array" to a function call in C. You will instead
pass the *value* of a *pointer* to a contiguous region of RAM which
contains th
Edward Bartolo writes:
> Now I have several exercises from "The C programming language"
> (Kernighan & Ritchie). Some question look rather challenging...
>
> I learnt arrays are always passed by reference to function calls.
As was already pointed out, all arguments to C functions are passed via
v
On Wed, Jun 22, 2016 at 10:35:39AM +0200, Stephan Seitz wrote:
> On Wed, Jun 22, 2016 at 08:08:38AM +0100, Simon Hobson wrote:
> >But once you go down the route of udev (or equivalent, eg vdev) and
> >persistent rules, then "eth0" is just a subset of "admin set interface
> >name".
>
> The problem
Didier Kryn writes:
> Le 22/06/2016 09:08, Simon Hobson a écrit :
>> If you just use the default kernel naming scheme then you open
>> yourself to the problem that udev was designed to solve - that of
>> random device names. I do have personal experience of that - boot
>> with a different disk (fo
Simon Hobson writes:
> Rainer Weikusat wrote:
>
>>> All in all, the easiest way by far is to use stable and user(admin)
>>> set names for interfaces !
>>
>> This is going to bite you in the posterior in case of canned OS
>> installations intended to be usable on a wide range of differently
>> co
On Wed, Jun 22, 2016 at 01:46:43PM +0200, emnin...@riseup.net wrote:
[cut]
>
> Thanks for your pointer. So, essentially, there is no way to play
> around the need of root.
>
Well, if you are not root, and you cannot become root, or you cannot
email root and ask him a favour, it might be quite
On Wed, 22 Jun 2016 13:46:43 +0200, Emninger wrote:
> Am Wed, 22 Jun 2016 08:35:48 +
> schrieb KatolaZ :
>> The easiest way is to have a cron script that runs once a day, with
>> root provileges, and calls "apt-get update".
[...]
> Thanks for your pointer. So, essentially, there is no way to p
On Wed, 22 Jun 2016 12:35:22 +0100, Simon Hobson wrote:
> On 21 Jun 2016, at 18:50, Irrwahn wrote:
>> Source code is written for humans, not machines! Clarity and
>> simplicity can help minimize code maintenance cost, and thus
>> easily outweigh some slight runtime penalty. Whoever has found
>>
Am Wed, 22 Jun 2016 08:35:48 +
schrieb KatolaZ :
Hi KatolaZ!
> The easiest way is to have a cron script that runs once a day, with
> root provileges, and calls "apt-get update". Then, your notifier could
> be as simple as:
>
> apt-get -s upgrade | grep "^[0-9]* upgr" | cut -d " " -f 1
>
>
Rainer Weikusat wrote:
> Lastly, if the target system is Linux (as here), one can safely assume
> that EBCDIC won't be used.
>
> None of this matter anyhow for solving algorithm exercises in an
> entry-level book about a programming language.
On the other hand, it might just give a newbie to C
Le 22/06/2016 09:08, Simon Hobson a écrit :
If you just use the default kernel naming scheme then you open yourself to the problem that udev was
designed to solve - that of random device names. I do have personal experience of that - boot with a
different disk (for maintenance) and eth0 & eth1
On 22/06/16 08:20, KatolaZ wrote:
> On Wed, Jun 22, 2016 at 02:15:17AM +0200, emnin...@riseup.net wrote:
> The easiest way is to have a cron script that runs once a day, with
> root provileges, and calls "apt-get update".
another way of periodically updating the lists of packages is to add
this
On Wed, 22 Jun 2016 11:15:44 +0200, Edward Bartolo wrote:
> I learnt arrays are always passed by reference to function calls. So,
KatolaZ already posted a very clear and correct comment
regarding by-reference vs. by-value, but anyway:
It is a fact that there are no *references* in C, but only
On Wed, Jun 22, 2016 at 11:15:44AM +0200, Edward Bartolo wrote:
> Hi,
>
> Now I have several exercises from "The C programming language"
> (Kernighan & Ritchie). Some question look rather challenging...
>
> I learnt arrays are always passed by reference to function calls. So,
> I wrote the follow
Hi,
Now I have several exercises from "The C programming language"
(Kernighan & Ritchie). Some question look rather challenging...
I learnt arrays are always passed by reference to function calls. So,
I wrote the following program to make use of this so that a variable
in main() is modified in a
On Wed, Jun 22, 2016 at 08:08:38AM +0100, Simon Hobson wrote:
But once you go down the route of udev (or equivalent, eg vdev) and
persistent rules, then "eth0" is just a subset of "admin set interface
name".
The problem with udev and eth0 is, that you have race conditions if you
let udev rena
Rainer Weikusat wrote:
>> All in all, the easiest way by far is to use stable and user(admin)
>> set names for interfaces !
>
> This is going to bite you in the posterior in case of canned OS
> installations intended to be usable on a wide range of differently
> configured 'servers' and not supp
35 matches
Mail list logo
