Re: [DNG] Download iso 32bit devuan alpha2 or higher(based installation without network)
On Thu, 3/31/16, Ismael L. Donis Garcia wrote: Subject: [DNG] Download iso 32bit devuan alpha2 or higher(based installation without network) To: "Lista de Devuan" Date: Thursday, March 31, 2016, 11:47 AM Where can I find a devuan 32 bit iso alpha2 or higher than the minimum system is installed without access to the network? if alpha4 better Someone could provide me a link to the download if you have it built? I want to keep trying at home where I do not have internet access. From now thanks | ISMAEL | You might want to give Refracta based on devuan jessie a try. fsmithred talks about it here in answer to a question similar to yours: http://refracta.freeforums.org/2016-02-23-iso-packages-t560.html#p5336 golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] systemd installed and running in default desktop
Am I the only one who hasn't noticed this yet? What am I missing? ( posted in parallel at: https://git.devuan.org/devuan-packages/sysvinit/issues/14 ) I installed the default devuan desktop package today, using the devuan installer, and on my first boot, instead of using the graphical installer, I proceeded to C-M-F1 for a command-line login. Upon logging in, I received a message: error message: systemd-logind[3096]: failed to start user service: unknown unit: user@1000.service When I later escalated to su, I received a similar error message. ps -aux | grep systemd shows a root process for /lib/systemd/systemd-logind The same command on any Manjaro/OpenRC flavor I use yields no systemd processes whatsoever. dpkg -l |grep systemd systemd 215-17+deb8u3 systemd-shim 9-1 sysv-rc 2.88dsf-59.2+devuan2 sysvinit-core 2.88dsf-59.2+devuan2 sysviniit-utils 2.88dsf-59.2+devuan2 Again, comparing with Manjaro/OpenRC, the only package with even a passing reference to systemd is: pacman -Q | grep systemd eudev-systemdcompat 228-1 sources.list deb-src http://us.mirror.devuan.org/merged/ jessie main non-free contrib deb http://security.debian.org/ jessie/updates main contrib non-free deb-src http://security.debian.org/ jessie/updates main contrib non-free # jessie-updates, previously known as 'volatile' deb http://us.mirror.devuan.org/merged/ jessie-updates main contrib non-free deb-src http://us.mirror.devuan.org/merged/ jessie-updates main contrib non-free # jessie-backports, previously on backports.debian.org deb http://us.mirror.devuan.org/merged/ jessie-backports main contrib non-free deb-src http://us.mirror.devuan.org/merged/ jessie-backports main contrib non-free -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote: > Hi, > > On 03/31/16 13:38, Emiliano Marini wrote: > >Besides, * and [] are interchangeable. You can define a string as an array > >and use it later as a pointer: > > > >char s[] = "hola"; > >char x = s[1]; // Here x = 'o' > >char y = *(s+2); // Here y = 'l' > > > >And vice versa: > > > >char *s = "hola"; > >char x = s[0]; // Here x = 'h' > >char y = *(s+3); // Here y = 'a' > > This is right, and the following sintax are analogous: > > *(p+i) <---> p[i] In fact, in the original C specification, p[i] was *defined* to mean *(p+i). -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Thu, Mar 31, 2016 at 03:18:17PM +0100, KatolaZ wrote: > On Thu, Mar 31, 2016 at 03:12:32PM +0200, Edward Bartolo wrote: > > Hi, thanks for taking time to reply, > > > > KatolaZ wrote: > > >> c) type **ss; // declare a pointer to pointer. System only allocates > > >> space for one address > > > > > C pointers are *always* one variable, precisely a variable large > > > enough to store a memory address on the current architecture. > > > > I think, I did not understand what you want to say. As far as I can > > imagine a pointer to pointer is something like this: > > [pointer1]-->[pointer2]--->[data] int the case of data** dt. > > > > OR > > > > [pointer1]-->[pointer2] in the case of void** ptr. > > Your example would be correct *only if* and pointer1, pointer2 actually contained proper addresses of memory instead of containing uninitialized junk or NULL. And that, I think, is what KatolaZ is tryng to point out. > > Nope. This is totally wrong. What you have in memory after a > declaration: > > type *a; > > is just *one variable*, namely a variable able to contain a memory > address. Yes. It is only when you actually assgn a pointer to a that your pointer->data diagram becomes valied. -- hendrik > When you declare: > > type **b; > > you still have exactly *one variable* allocated in memory, namely one > variable able to contain a memory address, and not *two variables* as > in your example above. This does not depend on what "type" is, so > each of the following declarations: > > int *a; > double ***b; > void c; > myowntype **d; > > will result in the allocation of exactly *one variable*, namely a > variable large enough to contain a pointer (i.e., a memory address). I > don't want to confuse you, but in my example myowntype might also be > declared as: > > typedef char*** myowntype; > > and still the declaration: > > myowntype **d; > > will reserve exactly one variable in memory, namely a variable large > enough to contain a memory address. > > The declaration is used only by the compiler to understand what is the > implicit semantic of the pointer arithmetic to be used with that > pointer, and to check that you are not palying nastly with it, so that > > int *p; > ... > p += 1; > > assigns to p the address of the memory location which is 1*sizeof(int) > bytes after the old address stored into p, while: > > double *p; > ... > p +=2; > > will assign to p the address of the memory location which is > 2*sizeof(double) bytes after the old address stored in p. > > You have not broken the pointers spell, yet. I warmly suggst you to > read a good introduction to C pointers, but the only thing that comes > to my mind is the Kernighan and Ritchie, which I admit is not the > easiest book around (although it is certainly the best on the > subject). > > My2Cents > > KatolaZ > > -- > [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] > [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] > [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] > [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Download iso 32bit devuan alpha2 or higher(based installation without network)
Where can I find a devuan 32 bit iso alpha2 or higher than the minimum system is installed without access to the network? if alpha4 better Someone could provide me a link to the download if you have it built? I want to keep trying at home where I do not have internet access. From now thanks | ISMAEL | ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Thu, Mar 31, 2016 at 03:12:32PM +0200, Edward Bartolo wrote: > Hi, thanks for taking time to reply, > > KatolaZ wrote: > >> c) type **ss; // declare a pointer to pointer. System only allocates > >> space for one address > > > C pointers are *always* one variable, precisely a variable large > > enough to store a memory address on the current architecture. > > I think, I did not understand what you want to say. As far as I can > imagine a pointer to pointer is something like this: > [pointer1]-->[pointer2]--->[data] int the case of data** dt. > > OR > > [pointer1]-->[pointer2] in the case of void** ptr. > Nope. This is totally wrong. What you have in memory after a declaration: type *a; is just *one variable*, namely a variable able to contain a memory address. When you declare: type **b; you still have exactly *one variable* allocated in memory, namely one variable able to contain a memory address, and not *two variables* as in your example above. This does not depend on what "type" is, so each of the following declarations: int *a; double ***b; void c; myowntype **d; will result in the allocation of exactly *one variable*, namely a variable large enough to contain a pointer (i.e., a memory address). I don't want to confuse you, but in my example myowntype might also be declared as: typedef char*** myowntype; and still the declaration: myowntype **d; will reserve exactly one variable in memory, namely a variable large enough to contain a memory address. The declaration is used only by the compiler to understand what is the implicit semantic of the pointer arithmetic to be used with that pointer, and to check that you are not palying nastly with it, so that int *p; ... p += 1; assigns to p the address of the memory location which is 1*sizeof(int) bytes after the old address stored into p, while: double *p; ... p +=2; will assign to p the address of the memory location which is 2*sizeof(double) bytes after the old address stored in p. You have not broken the pointers spell, yet. I warmly suggst you to read a good introduction to C pointers, but the only thing that comes to my mind is the Kernighan and Ritchie, which I admit is not the easiest book around (although it is certainly the best on the subject). My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On 03/31/16 16:07, KatolaZ wrote:
On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote:
[cut]
> >On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat <
> >rainerweiku...@virginmedia.com> wrote:
> >
> >There's one
> >>important difference:
> >>
> >>char chars[] = "12345";
> >>
> >>cause the compiler to reserve six bytes (five chars + terminating 0) in
> >>some location the program can write to. Afterwards,
> >>
> >>*chars = R;
> >>
> >>could be used to change the string to R2345.
>
>This is because
>
>*chars <---> *(chars+0) <---> chars[0]
>
>are analogous. So, chars[0] changes from 1 to R.
>
Again. being pedantic here the assignment:
*chars = R;
assigns the value of the variable R (which should be a char) to the
first byte of the memory area pointed by chars. If you we want to
change the first character of the string into the letter 'R', we
should write:
*chars = 'R';
Notice the (sometimes misleading and) subtle difference between single
quotes ('), which are used for character constants, and double quotes
(") which are used to delimit strings (i.e., they are the syntactic
sugar around constant arrays of char).
My2Cents
KatolaZ
Uppps :)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
Edward Bartolo:
> KatolaZ wrote:
> >> c) type **ss; // declare a pointer to pointer. System only allocates
> >> space for one address
>
> > C pointers are *always* one variable, precisely a variable large
> > enough to store a memory address on the current architecture.
>
> I think, I did not understand what you want to say. As far as I can
> imagine a pointer to pointer is something like this:
> [pointer1]-->[pointer2]--->[data] int the case of data** dt.
...
To be picky, "int ** id;", just defines an allocates one variable id
that when used like **id will have the type int. It says nothing about
what value id, *id, **id will have, nor if *id or **id will be in any
way useful.
For **id be useful *id has to have some defined value, e.g.
int main(void) {
int data = 4;
int * pointer1 = & data;
int ** pointer2 = & pointer1;
int *** pointer3 = & pointer2;
int pointer4 = & pointer3;
/* etc... */
return pointer4;
}
$ gcc -Wall a.c; ./a.out; echo $?
4
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote:
[cut]
> >On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat <
> >rainerweiku...@virginmedia.com> wrote:
> >
> >There's one
> >>important difference:
> >>
> >>char chars[] = "12345";
> >>
> >>cause the compiler to reserve six bytes (five chars + terminating 0) in
> >>some location the program can write to. Afterwards,
> >>
> >>*chars = R;
> >>
> >>could be used to change the string to R2345.
>
> This is because
>
> *chars <---> *(chars+0) <---> chars[0]
>
> are analogous. So, chars[0] changes from 1 to R.
>
Again. being pedantic here the assignment:
*chars = R;
assigns the value of the variable R (which should be a char) to the
first byte of the memory area pointed by chars. If you we want to
change the first character of the string into the letter 'R', we
should write:
*chars = 'R';
Notice the (sometimes misleading and) subtle difference between single
quotes ('), which are used for character constants, and double quotes
(") which are used to delimit strings (i.e., they are the syntactic
sugar around constant arrays of char).
My2Cents
KatolaZ
--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
Hi, On 03/31/16 13:38, Emiliano Marini wrote: Besides, * and [] are interchangeable. You can define a string as an array and use it later as a pointer: char s[] = "hola"; char x = s[1]; // Here x = 'o' char y = *(s+2); // Here y = 'l' And vice versa: char *s = "hola"; char x = s[0]; // Here x = 'h' char y = *(s+3); // Here y = 'a' This is right, and the following sintax are analogous: *(p+i) <---> p[i] *(*(p+i)+j) <---> p[i][j] This last one in the case of a double pointer. On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat < rainerweiku...@virginmedia.com> wrote: There's one >important difference: > >char chars[] = "12345"; > >cause the compiler to reserve six bytes (five chars + terminating 0) in >some location the program can write to. Afterwards, > >*chars = R; > >could be used to change the string to R2345. This is because *chars <---> *(chars+0) <---> chars[0] are analogous. So, chars[0] changes from 1 to R. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
Hi, thanks for taking time to reply,
KatolaZ wrote:
>> c) type **ss; // declare a pointer to pointer. System only allocates
>> space for one address
> C pointers are *always* one variable, precisely a variable large
> enough to store a memory address on the current architecture.
I think, I did not understand what you want to say. As far as I can
imagine a pointer to pointer is something like this:
[pointer1]-->[pointer2]--->[data] int the case of data** dt.
OR
[pointer1]-->[pointer2] in the case of void** ptr.
Edward
On 31/03/2016, KatolaZ wrote:
> On Thu, Mar 31, 2016 at 08:38:26AM -0300, Emiliano Marini wrote:
>> +1
>>
>> Besides, * and [] are interchangeable. You can define a string as an array
>> and use it later as a pointer:
>>
>> char s[] = "hola";
>> char x = s[1]; // Here x = 'o'
>> char y = *(s+2); // Here y = 'l'
>>
>> And vice versa:
>>
>> char *s = "hola";
>> char x = s[0]; // Here x = 'h'
>> char y = *(s+3); // Here y = 'a'
>>
>
> Just to be pedantic here, "[]" is just syntactic sugar around the
> dereference operator "*". And in fact "[]" did not even exist in the
> first versions of proto-C. Obviously, "[]" is syntactic sugar around
> unary "*" for *any* kind of pointer, not just for strings.
>
> Also, initialisation of char* and char[] by means of
>
> char s[] = "hello";
>
> is syntactic sugar around the generic initialiser:
>
> type p = {...};
>
> which allows to initialise arrays and compound variables (structs and
> unions) as well. But be careful with statically initialised strings,
> since they are effectively constant char pointers (they are stored in
> the current stack frame, not in the heap, and the address stored in
> such variables cannot be modified, AFAIR).
>
> My2Cents
>
> KatolaZ
>
> --
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Thu, Mar 31, 2016 at 08:38:26AM -0300, Emiliano Marini wrote:
> +1
>
> Besides, * and [] are interchangeable. You can define a string as an array
> and use it later as a pointer:
>
> char s[] = "hola";
> char x = s[1]; // Here x = 'o'
> char y = *(s+2); // Here y = 'l'
>
> And vice versa:
>
> char *s = "hola";
> char x = s[0]; // Here x = 'h'
> char y = *(s+3); // Here y = 'a'
>
Just to be pedantic here, "[]" is just syntactic sugar around the
dereference operator "*". And in fact "[]" did not even exist in the
first versions of proto-C. Obviously, "[]" is syntactic sugar around
unary "*" for *any* kind of pointer, not just for strings.
Also, initialisation of char* and char[] by means of
char s[] = "hello";
is syntactic sugar around the generic initialiser:
type p = {...};
which allows to initialise arrays and compound variables (structs and
unions) as well. But be careful with statically initialised strings,
since they are effectively constant char pointers (they are stored in
the current stack frame, not in the heap, and the address stored in
such variables cannot be modified, AFAIR).
My2Cents
KatolaZ
--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Thu, Mar 31, 2016 at 08:38:26AM -0300, Emiliano Marini wrote: > +1 > > Besides, * and [] are interchangeable. You can define a string as an array > and use it later as a pointer: > > char s[] = "hola"; > char x = s[1]; // Here x = 'o' > char y = *(s+2); // Here y = 'l' > > And vice versa: > > char *s = "hola"; > char x = s[0]; // Here x = 'h' > char y = *(s+3); // Here y = 'a' Bit sizeof(s) will not be the sae iin the two versions. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Wed, Mar 30, 2016 at 10:40:37PM +0200, Edward Bartolo wrote: > Hi, thanks for your help. > > So: [ I am recalling this from memory to test where I am ] > a) type* pp; // declare a pointer pp > b) *pp = RHS; // assign RHS to the data pointed to by pp This is a bit fishy, and should be taken with care. In a word, you should be very careful about what is in the RHS, and you should be sure that whatever is on the RHS "fits" in the memory area starting at the location stored into pp. > c) type **ss; // declare a pointer to pointer. System only allocates > space for one address C pointers are *always* one variable, precisely a variable large enough to store a memory address on the current architecture. > d) *ss = RHS; // assign RHS to the pointer pointed to by ss. This is no different from b) above, is it? > e) const char* and char* are not the same ie treated differently by the > compiler "const" is a qualifier that modifies what you can do with a pointer. If a pointer is declared "const" (usually in the signature of a function), then any assignment that directly tries to change the value of that pointer should be forbidden at compile time. I say "should" because some compilers simply ignore the "const" qualifier. > f) strings are character arrays, so they obey the rules governing arrays Definitely. A string is just an array of char, and the variable you use to handle strings is a char*. The usual pointer arithmetics holds for any kind of pointer, including char*. > g) strings are terminated by a null character which is a byte with eight zeros This only makes sense if you want to use the standard functions to handle strings. Nothing forbids you for creating and handling by your own an array or chars (identified by a char*) which is not null-terminated. > h) extra care must be taken when copying strings not to write beyond > the end of allocated memory. This can result in buffer overflows that > may cause execution of arbitrary code Extra care should be taken when copying between *any* two memory areas, and strings are not an exception. > i) some built in string function provided by C, especially vintage > string functions, suffer from the buffer overrun bug. Guard against > that by making sure there is enough memory allocated. > j) When calling backend CLI programs make sure, the input to the > calling function cannot be maliciously modified to allow execution of > arbitrary commands. Functions like execl can be abused so extra care > to block abuse must be taken. This is generally true, but has nothing much to do with the previous points. My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
+1 Besides, * and [] are interchangeable. You can define a string as an array and use it later as a pointer: char s[] = "hola"; char x = s[1]; // Here x = 'o' char y = *(s+2); // Here y = 'l' And vice versa: char *s = "hola"; char x = s[0]; // Here x = 'h' char y = *(s+3); // Here y = 'a' On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat < rainerweiku...@virginmedia.com> wrote: > Edward Bartolo writes: > > > Hi, thanks for your help. > > > > So: [ I am recalling this from memory to test where I am ] > > a) type* pp; // declare a pointer pp > > b) *pp = RHS; // assign RHS to the data pointed to by pp > > c) type **ss; // declare a pointer to pointer. System only allocates > > space for one address > > (1) Background > -- > > The C type system is built around the idea that certain kind of types can > be > derived from already existing types. These are pointers, arrays (and > functions, but I'm going to omit them for simplicity). Eg, assuming type > identifies and existing type, > > type *pt > > declares a pointer to objects of type type and > > type at[3]; > > declares an array of objects of type type. When an object is defined, > the system allocates storage for it in some suitable location, eg, on > the stack or by reserving a register. > > (2)Typedef names > > > It's possible to create a new name for an existing type with the help of > typedef, eg, after > > typedef int *pint; > > pint can be used as type name to mean 'pointer to int'. Eg, > > pint pi; > > would define an object of type 'pointer to int' (the compiler will > allocate storage for). > > Pulling this together > - > > Assuming pint is declared as above. As per (1), new types can now > derived from it, eg, > > pint *ppi; /* "Dear customer ..." */ > > This defines a "pointer to pint", hence, the system allocates storage > for one. But that's really the same as > > int **ppi; > > which is handled in exactly the same way: An object with a pointer type > derived from some existing type is defined. Hence, storage for a pointer > is reserved. That the existing type is itself a pointer type doesn't > matter, for the given purpose, it's just 'some type'. > > > > f) strings are character arrays, so they obey the rules governing arrays > > They're really pointers to character arrays. Because an array is > converted to a pointer to its first element most of the time, a > character array, say > > char chars[] = "12345"; > > can be used as if it had been declared as a pointer. There's one > important difference: > > char chars[] = "12345"; > > cause the compiler to reserve six bytes (five chars + terminating 0) in > some location the program can write to. Afterwards, > > *chars = R; > > could be used to change the string to R2345. In contrast to this. > > char *chars = "12345"; > > causes the compiler to allocate storage for a writable char * and > initialize that with the address of a string literal which is not > required to be (and usually won't be) writeable. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
Exactly, any local variable comes off the stack, but I was talking about pointers :) On Wed, Mar 30, 2016 at 3:37 PM, Steve Litt wrote: > On Wed, 30 Mar 2016 08:23:16 -0300 > Emiliano Marini wrote: > > > Edward, the only time the compiler allocates memory for data > > automatically is when using strings literals (as stated by Rainer > > previously) > > > > char *p = "Hola mundo." > > Also when you have a struct as a local variable: > > struct my_cool_struct mystruct; > > Like the char pointer, it comes off the stack, not the heap it would > come off if you used malloc(). > > Actually, any local variable allocates memory off the stack. Consider: > > int number_of_people; > > The preceding allocates sizeof(int) bytes, for number_of_people, off > the stack. > > SteveT > > Steve Litt > March 2016 featured book: Quit Joblessness: Start Your Own Business > http://www.troubleshooters.com/startbiz > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
