Re: [DNG] simple-netaid from scratch
Hi Didier, En 12 de junio de 2019 7:40:08 Didier Kryn escribió: sizeof() is not a real function. Its syntax makes it look like a function but it is not. Its argument can be either a variable or a type (which no function can have). It is evaluated at compile time - which is equivalent to replacing it with the litteral value. Didier But, in this concrete case, the size can be evaluated at compile time because the memory is asigned statically by using a char array (instead of a char* pointer). In the case of a dinamic memory asignment (runtime), the size would be the value of the N variable used in the malloc function. BTW, i recently added the systray icon to simple-netaid: https://git.devuan.org/aitor_czr/simple-netaid/blob/master/screenshots/systray-icon.png Cheers, Aitor. Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Enviado con AquaMail para Android https://www.mobisystems.com/aqua-mail ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
Le 11/06/2019 à 20:40, Steve Litt a écrit : On Mon, 10 Jun 2019 15:01:53 +0100 s@po wrote: On Mon, 10 Jun 2019 13:34:54 +0100 (BST) Jim Jackson wrote: sizeof() is calculated by the compiler, not at run time. The code generated would be the same. Hello Jim, Indeed it his, my point was only a observation, that if size is fixed, no need to calculate it at compile time, the preprocessor can solve that with a macro.. The code generated will be indeed the same. Only was a observation ;) I vote for leaving it as a function. What would be gained by making it a macro? A microsecond? What are the bottlenecks of the software? Are keyboard or mouse input involved? If these sizeof() calls are deep in a tight nested loop, by all means make them into a macro. Otherwise, why give up the simplicity of a function for the sometimes edge case weirdness of a macro? It's funny. So many times people advocate jumping through hoops to save a millisecond in a program operated by and therefore bottlenecked by a 100wpm typist. 100wpm is 500 keystrokes per minute, or 8.33 keystrokes per second, which means each keystroke takes 120 milliseconds. The 1ms savings *just doesn't matter*. And yes, as a matter of fact, I often do use "useless use of cat". Costs me nothing perceptible, and makes it easier to rearrange pipelines til I get them right. I fully agree that gaining milisecond is often futile. But this has nothing to do with this discussion. The discussion was only about style. sizeof() is not a real function. Its syntax makes it look like a function but it is not. Its argument can be either a variable or a type (which no function can have). It is evaluated at compile time - which is equivalent to replacing it with the litteral value. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Tue, 11 Jun 2019 22:07:22 +0100 (BST) Jim Jackson wrote: > On Tue, 11 Jun 2019, Steve Litt wrote: > > > On Mon, 10 Jun 2019 15:01:53 +0100 > > s@po wrote: > > > > > On Mon, 10 Jun 2019 13:34:54 +0100 (BST) > > > Jim Jackson wrote: > > > > > > > > > > > sizeof() is calculated by the compiler, not at run time. The > > > > code generated would be the same. > > > > > > Hello Jim, > > > Indeed it his, my point was only a observation, that if size is > > > fixed, no need to calculate it at compile time, the preprocessor > > > can solve that with a macro.. The code generated will be indeed > > > the same. Only was a observation ;) > > > > I vote for leaving it as a function. > > > > What would be gained by making it a macro? A microsecond? What are > > the bottlenecks of the software? Are keyboard or mouse input > > involved? > > > > If these sizeof() calls are deep in a tight nested loop, by all > > means make them into a macro. Otherwise, why give up the simplicity > > of a function for the sometimes edge case weirdness of a macro? > > I do wish people would read. Those sizeof()'s are not executable > functions, they are calculated by the compiler at compile time into > their fixed numbers and inserted into the code as fixed numbers, just > as a macro would! There is no difference at runtime. The code > generated would be identical. > > There is no execution penalty to using sizeof()! Then sizeof() is perfect for the job. SteveT Steve Litt June 2019 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Tue, 11 Jun 2019, Steve Litt wrote: > On Mon, 10 Jun 2019 15:01:53 +0100 > s@po wrote: > > > On Mon, 10 Jun 2019 13:34:54 +0100 (BST) > > Jim Jackson wrote: > > > > > > > > sizeof() is calculated by the compiler, not at run time. The code > > > generated would be the same. > > > > Hello Jim, > > Indeed it his, my point was only a observation, that if size is > > fixed, no need to calculate it at compile time, the preprocessor can > > solve that with a macro.. The code generated will be indeed the same. > > Only was a observation ;) > > I vote for leaving it as a function. > > What would be gained by making it a macro? A microsecond? What are the > bottlenecks of the software? Are keyboard or mouse input involved? > > If these sizeof() calls are deep in a tight nested loop, by all means > make them into a macro. Otherwise, why give up the simplicity of a > function for the sometimes edge case weirdness of a macro? I do wish people would read. Those sizeof()'s are not executable functions, they are calculated by the compiler at compile time into their fixed numbers and inserted into the code as fixed numbers, just as a macro would! There is no difference at runtime. The code generated would be identical. There is no execution penalty to using sizeof()! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Tuesday 11 June 2019 at 20:40:09, Steve Litt wrote: > It's funny. So many times people advocate jumping through hoops to save > a millisecond in a program operated by and therefore bottlenecked by a > 100wpm typist. 100wpm is 500 keystrokes per minute, If I may pick a nit, I think it makes the succeeding arithmetic slightly simpler. I believe 100wpm is 600 keystrokes per minute, because the "standard word" is 5 letters, but there's also a space between the words? > or 8.33 keystrokes per second, 600 per minute is 10 per second - much neater :) > which means each keystroke takes 120 milliseconds. 100ms... > The 1ms savings *just doesn't matter*. Agreed :) > And yes, as a matter of fact, I often do use "useless use of cat". > Costs me nothing perceptible, and makes it easier to rearrange > pipelines til I get them right. Antony. -- It is also possible that putting the birds in a laboratory setting inadvertently renders them relatively incompetent. - Daniel C Dennett Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Mon, 10 Jun 2019 15:01:53 +0100 s@po wrote: > On Mon, 10 Jun 2019 13:34:54 +0100 (BST) > Jim Jackson wrote: > > > > > sizeof() is calculated by the compiler, not at run time. The code > > generated would be the same. > > Hello Jim, > Indeed it his, my point was only a observation, that if size is > fixed, no need to calculate it at compile time, the preprocessor can > solve that with a macro.. The code generated will be indeed the same. > Only was a observation ;) I vote for leaving it as a function. What would be gained by making it a macro? A microsecond? What are the bottlenecks of the software? Are keyboard or mouse input involved? If these sizeof() calls are deep in a tight nested loop, by all means make them into a macro. Otherwise, why give up the simplicity of a function for the sometimes edge case weirdness of a macro? It's funny. So many times people advocate jumping through hoops to save a millisecond in a program operated by and therefore bottlenecked by a 100wpm typist. 100wpm is 500 keystrokes per minute, or 8.33 keystrokes per second, which means each keystroke takes 120 milliseconds. The 1ms savings *just doesn't matter*. And yes, as a matter of fact, I often do use "useless use of cat". Costs me nothing perceptible, and makes it easier to rearrange pipelines til I get them right. SteveT Steve Litt June 2019 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
Le 10/06/2019 à 20:20, s@po a écrit : One harmfull situation is when you pass an array[n] to a function has an argument, for example.. Usign 'sizeof' inside, will return the size of the pointer and not the size of elements on the array.. It is a "beginner's" error to confuse the size of the pointer with the size of the pointed. Indeed there are many "beginner's" errors possible in C. But it's not the same story. I admit that I have often used sizeof(array)/sizeof(element) to mean the number of elements. But when I realized - recently - that it was an artefact relying on the compiler and not on the language, and not semantically true, I stopped. I would now prefer using a macro as you suggested, or a constant. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Mon, 10 Jun 2019 17:58:35 +0200
Didier Kryn wrote:
> Le 10/06/2019 à 16:01, s@po a écrit :
> > On Mon, 10 Jun 2019 13:34:54 +0100 (BST)
> > Jim Jackson wrote:
> >
> >> sizeof() is calculated by the compiler, not at run time. The code
> >> generated would be the same.
> > Hello Jim,
> > Indeed it his, my point was only a observation, that if size is fixed, no
> > need to calculate it at compile time, the preprocessor can solve that with
> > a macro..
> > The code generated will be indeed the same.
> > Only was a observation ;)
> >
> \begin{pedantic}
> The size used by the layout of the data (sizeof()) has not the same
> meaning as the number of elements. AFAIK, the C language does not
> specify (at least not completely) the data layout and leaves it to the
> implementation.
> All modern hardware lay out data as bit octets and compilers use
> one octet of bits to represent an ASCII character (note 7 would suffice
> for ASCII). All compilers layout strings in contiguous successive octets.
> Therefore there is little chance that the confusion between size
> and number of elements be harmfull. Yet there is a subtle difference :~)
> \end{pedantic}
>
Indeed,
One harmfull situation is when you pass an array[n] to a function has an
argument, for example..
Usign 'sizeof' inside, will return the size of the pointer and not the size of
elements on the array..
unsigned char funtion test( unsigned char *array ){
/* This will not return the size of array,
but instead, the size of the Pointer..,
because at compile time, compiler doesn't know what size array[n] will
have */
return sizeof( array )
}
Regards,
--
tux
s@po
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
Le 10/06/2019 à 16:01, s@po a écrit :
On Mon, 10 Jun 2019 13:34:54 +0100 (BST)
Jim Jackson wrote:
sizeof() is calculated by the compiler, not at run time. The code
generated would be the same.
Hello Jim,
Indeed it his, my point was only a observation, that if size is fixed, no need
to calculate it at compile time, the preprocessor can solve that with a macro..
The code generated will be indeed the same.
Only was a observation ;)
\begin{pedantic}
The size used by the layout of the data (sizeof()) has not the same
meaning as the number of elements. AFAIK, the C language does not
specify (at least not completely) the data layout and leaves it to the
implementation.
All modern hardware lay out data as bit octets and compilers use
one octet of bits to represent an ASCII character (note 7 would suffice
for ASCII). All compilers layout strings in contiguous successive octets.
Therefore there is little chance that the confusion between size
and number of elements be harmfull. Yet there is a subtle difference :~)
\end{pedantic}
Didier
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Mon, 10 Jun 2019 13:34:54 +0100 (BST) Jim Jackson wrote: > > sizeof() is calculated by the compiler, not at run time. The code > generated would be the same. Hello Jim, Indeed it his, my point was only a observation, that if size is fixed, no need to calculate it at compile time, the preprocessor can solve that with a macro.. The code generated will be indeed the same. Only was a observation ;) Best Regards, -- tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Sat, 8 Jun 2019, s@po wrote: > On Sat, 1 Jun 2019 08:31:49 + > aitor_czr wrote: > > Hello aitor, > > > > > Look at the "netstat.c" file again. I'm using > > > > status = fgets ( buffer, sizeof(buffer), fp ); > > > > instead :) > > > > Aitor. > > > > > > I understood that, from the beguining.. :) > You don't need the 'sizeof *buffer', since you have a fixed array size of 512 > bytes.. > And a byte, is a byte in 32 bits or 64 bits systems ;) > > Becasue of that, I suggested changing it to: > #define BUFFER_SIZE 512 > > and then: > status = fgets ( buffer, BUFFER_SIZE, fp ); > > It was only a sugestion ;) > Its not wrong, to use it( even tough you are heavilly relying on that unary > operator.. for a fixed array size, of n bytes.. ) > sizeof() is calculated by the compiler, not at run time. The code generated would be the same. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Sat, 1 Jun 2019 08:31:49 + aitor_czr wrote: Hello aitor, > > Look at the "netstat.c" file again. I'm using > > status = fgets ( buffer, sizeof(buffer), fp ); > > instead :) > > Aitor. > > I understood that, from the beguining.. :) You don't need the 'sizeof *buffer', since you have a fixed array size of 512 bytes.. And a byte, is a byte in 32 bits or 64 bits systems ;) Becasue of that, I suggested changing it to: #define BUFFER_SIZE 512 and then: status = fgets ( buffer, BUFFER_SIZE, fp ); It was only a sugestion ;) Its not wrong, to use it( even tough you are heavilly relying on that unary operator.. for a fixed array size, of n bytes.. ) Best Regards -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
Hi s@, On 20/5/19 22:41, s@ wrote: aitor_czr wrote: Have a look at the server side: https://git.devuan.org/aitor_czr/simple-netaid/blob/master/backend_src/server.c char buffer[512]; (...) You are using in some places 'sizeof(buffer)' in 'fgets()' and such.. Your buffer has a fixed size.. /* Somewere else, probably in the header file..*/ #define BUFFER_SIZE 512; (...) Yes, this is in the "netstat.c" file, but i didn't define any BUFFER_SIZE in the "netstat.h" header. char buffer[ BUFFER_SIZE ]; (...) status = fgets ( buffer, BUFFER_SIZE, fp ); its my 2 cents:) Regards, Look at the "netstat.c" file again. I'm using status = fgets ( buffer, sizeof(buffer), fp ); instead :) Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
On Sun, 19 May 2019 11:38:52 +0200 Hello aitor, aitor_czr wrote: > Have a look at the server side: > > https://git.devuan.org/aitor_czr/simple-netaid/blob/master/backend_src/server.c char buffer[512]; (...) You are using in some places 'sizeof(buffer)' in 'fgets()' and such.. Your buffer has a fixed size.. /* Somewere else, probably in the header file..*/ #define BUFFER_SIZE 512; (...) char buffer[ BUFFER_SIZE ]; (...) status = fgets ( buffer, BUFFER_SIZE, fp ); its my 2 cents :) Regards, -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] simple-netaid from scratch
Aitor wrote: "We must think on the devuan project, we hate narcissism :)" Narcissism is a delusion; there is nothing to like about it. During youth it prevents sufferers from identifying their weaknesses lowering their chances of success. I am using my version not to stroke my ego; that need to be disciplined, reality is far more important than living in an unreal world with far less chances of success. Embrace reality. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
Hi Edward, On 15/5/19 13:10, Edward Bartolo via Dng wrote: Hi Aitor, I, like many other Devuan users, hope that the last crises is over and that it will never happen again. The purpose of replying to your thread is to ask why you are rewriting the backend from the very beginning. I started rewriting the backend from the very begining due to some failures in the connection status systray icon and also in the connection attempts. But i started again rewriting it from scratch due to a wrong approach. Today i pushed to gitlab the client/server unix socket, and I'm happy with the result. You can test it running the server in a secondary plane: $ ./server & and running the client below: $ ./client getting the info about the network connection status at every second, something like this: Connected to wlp1s0 DEVICE_TYPE=Wireless IP Address=192.168.0.10 BROADCAST=192.168.0.255 NETMASK=255.255.255.0 PROTOCOL=IEEE 802.11 ESSID=Euskaltel-58YA QUALITY=94% Have a look at the server side: https://git.devuan.org/aitor_czr/simple-netaid/blob/master/backend_src/server.c concretly to the writeFileDescriptor ( int df, struct sbuf s ) function. It works as follows: - iproute() gives the first line of the output in the command line, that is: "Connected to " or "Disconnected" - In the case of a conneted state, netproc() will give us the information about the network connection, the rest of the output in the command line. I still didn't add the Mac address because the code (using "g_strdup_printf") requires Glib: https://git.devuan.org/aitor_czr/simple-netaid/blob/master/backend_src/netstat.c and i'm trying to avoid it (not for any specific reason). Needless to state, I am still using my version of simple-netaid with its simple graphical interface. However, this does not mean I will not consider better competitors. We must think on the devuan project, we hate narcissism :) Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] simple-netaid from scratch
Hi Aitor, I, like many other Devuan users, hope that the last crises is over and that it will never happen again. The purpose of replying to your thread is to ask why you are rewriting the backend from the very beginning. Needless to state, I am still using my version of simple-netaid with its simple graphical interface. However, this does not mean I will not consider better competitors. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] simple-netaid from scratch
Hi all, I recently started started developing the backend of simple-netaid from scratch. There will be a lot of improvements. You can find the project here: https://git.devuan.org/aitor_czr/simple-netaid/tree/master/ The readme file will contain all the documentation about usage of the CLI version of simple-netaid. The code contained in the current status are core versions of some features of iproute2, removing simple-netaid's dependency on the whole project. For example, the functions of the ipaddr.c file: https://git.devuan.org/aitor_czr/simple-netaid/blob/master/backend_src/ipaddr.c flushes all the previous ip addresses asigned to a concrete network interface,doing the same than: # ip addr flush dev I hope to finish this work as soon as possible in order to include the network manager in gnuinos ascii. Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
